OAuth2.0

以登录为例，介绍OAUTH2.0(RFC-6749)授权码模式流程：

 

1. 需登录的请求/aaa，被LoginInterceptor拦截
2. LoginInterceptor的工作：
   1. 请求公司的authorization_url  ( GET - https://xxxx/auth/oauth/authorize/)
   2. GET authorization_url必选参数：
      1. response_type：返回值类型，项目中接入的是授权码类型，code
      2. client_id：接入SSO的appid
      3. redirect_url：回跳地址，此处取callbackServlet对应的URL()
         1. redirect_url中携带/aaa的地址,处理完毕后跳转到发起请求的地方
   3. GET authorization_url可选参数：
      1. state：表示客户端的当前状态，AuthorizationServer会原封不动地返回该值，几乎必选
      2. scope：权限作用范围
3. Authorization Server的工作(authorization_url)：
   1. 根据response_type做出不同响应
   2. 以code为例：
      1. 检查client_id合法性
      2. 根据client_id等元数据生成一个授权码code,有效期一般在十分钟内,且只可使用一次
      3. 重定向到redirect_url，并携带code，state(if any)
4. CallbackController的工作：
   1. 从url中获取参数code
   2. 请求公司的ACCESS_TOKEN_URL ( GET - https://ee.byted.org/ratak/oauth/access_tokens/)
      1. 必选参数：
      2. AuthorizationHeader：Basic认证，格式为  client_id：client_pwd
      3. code：从步骤a中获得的授权码
   3. AuthorizationServer会对client_id&client_pwd&code进行校验，如果没有差错，将校验AS域名下的sessionID，如果用户登录状态没问题，则请求成功，生成token返回给callbackController
   4. 如果没有检测到有效的sessionID，则redirect到SSO系统，走单点登录的流程，成功后生成token返回给callbackController，过程比较复杂，此处不多赘述
   5. 存储这个token/自己需要的信息(例如emoloyee_id)
   6. callbackController的参数介绍：
      1. (可选) redirect_url： callbackController处理完毕后，需要将用户重定向到redirect_url，比如/aaa

 

---

思考：

【1】在步骤3中，AuthorizationServer为什么不直接返回token？

         直接返回token不安全。

         ①并非所有的服务都支持https。在此前提下，直接返回token，其值作为重定向URL的参数必然直接暴露在Client端。

         ②通过code做中转，token最终在callbackController中获得，降低了风险。

         ③在确保支持Https时，可以选择implict模式，具体参考RFC 6749。