- Oauth2授权
Oauth2的优点
- 短期的,自动失效。
- 可以撤销,撤销立即生效
- 有权限范围,如只能进一个门。
Oauth2的一般应用场景
为第三方系统授权登陆,比如京东使用qq的授权登陆。
- 选择后跳转到qq网站
- 录入qq的登陆信息,得到令牌
- 得到令牌后同意授权qq信息登陆京东京东使用令牌可以访问qq系统成功后,实现跳转。
其过程如下
OAuth2 的参与方
1客户端:京东
2资源服务器和授权服务器:QQ,持有资源,发放令牌
3OAuth2:授权协议
因为客户端和认证服务器之间不信任,从而产生一个授权协议,如果信任qq开放数据库。
Oauth2.0和1.0的区别
因为1.0的缺点比较多,所以大部分都使用2.0.
Oauth2是目前最流行的授权协议,用来授权第三方应用访问,获取用户数据。
java实现Oauth2协议的标准是Spring security Oauth2。
Resource Owner资源所有者:我
Client客户端:京东
Authorization Server 授权服务:QQ
Resource service 资源服务:QQ
User Agent 用户端代理:浏览器
- 授权模式
1.授权码模式,是最安全的,一次只能授权一个授权码,令牌保存在客户端服务器里,连浏览器都不知道令牌。
2.简化模式
申请后直接返回令牌,不是返回授权码。因为有的服务器可能无法保持令牌,从而直接获取令牌token。
3.密码模式
如果客户端和服务器高度信任,资源持有方把用户密码告诉客户端,对客户端高度信任。
4.客户端模式
直接以客户端端的名义申请令牌,用的很少。
所以我们T31的授权模式
前端想要访问其他模块则首先需要向Aouth2先获取令牌。。
授权服务器:auth-center
资源服务器:order
客户端:ui
为什么要使用Oauth2?
1.0单体时代:从架构演进的角度最开始的单体架构时使用cookie session机制。
2.0分布式架构时:使用session 共享
3.0基于token的分布式架构方案
对于Cookie session与token的区别
- cookie是不能跨域(域名,端口不同、协议不同),前后端分离分布式实现多系统SSO非常困难。
- 移动端应用没有cookie,所以对移动端支持不好。
- token是基于header传递,部分解决CSRF攻击,比cookie安全
- token比sessionID大,客户端存储在local storage中可以直接被JS读取。
OAuth2实战
java里实现OAuth2的标准是Spring Security OAuth2.
在T31中授权服务t31-auth-center和资源服务器图t31-cms,一般建议2者分开。
依赖框架
主要配置客户端信息
客户端存储令牌。
服务器端存储令牌
服务器端令牌其实可以不存在,jwt
开启Security的配置
来完成认证问题和用户权限问题。
随便校验一个令牌
- 资源服务器配置
定义了controller资源信息。
- 开启资源服务器
- 授权服务器令牌校验
资源服务器通过请求(url)向授权中心校验令牌
- 客户端信息
- Security配置
- 开启security
授权模式
- 授权码模式
授权流程如下,主要包括申请授权
1)申请授权码url
得到授权码,使用授权码
- 申请令牌
携带授权码请求申请令牌,还需要传递客户端身份信息
身份信息如下
- 得到令牌信息
因为令牌只能获取一次,重复调用就会提示已失效。
因为授权码与登录令牌是分2次分别得到,所以浏览器仅仅得到一个都无法访问,这样比较安全。
传递令牌方式:
- 可以通过浏览器url传递
- 通过header协带令牌信息传递,这样可以跨域了就。,
bearer类型就是在header里增加:bearer:令牌
- 简化模式
与授权模式区别就是申请授权后直接返回令牌(跳过了授权码步骤),当只有一个静态页面时可以使用这种模式,但是这种模式安全性比第1种低。
- 密码模式
客户端与授权中心和资源服务器非常信任,则可以使用这种模式访问。
可以使用密码方式申请令牌,没有浏览器先获取授权码,而是直接发送密码获取得令牌,表明客户端身份信息。
4.客户端模式
是指客户端使用自己的名义,而不是用户的名义向授权中心获取令牌。