以登录为例,介绍OAUTH2.0(RFC-6749)授权码模式流程:
- 需登录的请求/aaa,被LoginInterceptor拦截
- LoginInterceptor的工作:
- 请求公司的authorization_url ( GET - https://xxxx/auth/oauth/authorize/)
- GET authorization_url必选参数:
- response_type:返回值类型,项目中接入的是授权码类型,code
- client_id:接入SSO的appid
- redirect_url:回跳地址,此处取callbackServlet对应的URL()
- redirect_url中携带/aaa的地址,处理完毕后跳转到发起请求的地方
- GET authorization_url可选参数:
- state:表示客户端的当前状态,AuthorizationServer会原封不动地返回该值,几乎必选
- scope:权限作用范围
- Authorization Server的工作(authorization_url):
- 根据response_type做出不同响应
- 以code为例:
- 检查client_id合法性
- 根据client_id等元数据生成一个授权码code,有效期一般在十分钟内,且只可使用一次
- 重定向到redirect_url,并携带code,state(if any)
- CallbackController的工作:
- 从url中获取参数code
- 请求公司的ACCESS_TOKEN_URL ( GET - https://ee.byted.org/ratak/oauth/access_tokens/)
- 必选参数:
- AuthorizationHeader:Basic认证,格式为 client_id:client_pwd
- code:从步骤a中获得的授权码
- AuthorizationServer会对client_id&client_pwd&code进行校验,如果没有差错,将校验AS域名下的sessionID,如果用户登录状态没问题,则请求成功,生成token返回给callbackController
- 如果没有检测到有效的sessionID,则redirect到SSO系统,走单点登录的流程,成功后生成token返回给callbackController,过程比较复杂,此处不多赘述
- 存储这个token/自己需要的信息(例如emoloyee_id)
- callbackController的参数介绍:
- (可选) redirect_url: callbackController处理完毕后,需要将用户重定向到redirect_url,比如/aaa
思考:
【1】在步骤3中,AuthorizationServer为什么不直接返回token?
直接返回token不安全。
①并非所有的服务都支持https。在此前提下,直接返回token,其值作为重定向URL的参数必然直接暴露在Client端。
②通过code做中转,token最终在callbackController中获得,降低了风险。
③在确保支持Https时,可以选择implict模式,具体参考RFC 6749。