Oauth2.0及SSO原理
一.Oauth2.0四种授权模式及适用场景
1. Oauth2.0四种授权模式
1.授权码模式
假设
第三方应用域名为https://a.com
授权服务器域名为https://b.com
那么授权流程为:
- 浏览器访问授权服务器请求授权
https://b.com/oauth/auth?
response_type=code //表示使用授权码模式
&client_id=CLIENT_ID //第三方应用注册的id
&redirect_uri=CALLBACK_URL //用户授权后重定向的地址
&scope=read //授权范围
-
用户手动确认授权
-
授权服务器重定向到指定地址
https://a.com/callback?code=AUTHORIZATION_CODE //code就是授权码
- 第三方应用拿到授权码向授权服务器换取Token
#https://b.com/oauth/token?
client_id=CLIENT_ID //客户端id
&client_secret=CLIENT_SECRET //授权服务器的秘钥
&grant_type=authorization_code //表示使用的是授权码模式
&code=AUTHORIZATION_CODE //授权码
&redirect_uri=CALLBACK_URL //回调的地址
- 当授权服务器校验通过后会向指定的回调地址发送Token信息
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101
}
2.密码模式
3.简化模式
4.客户端模式
2.特点以及使用场景
1. 授权码模式:安全性高,使用率高,流程复杂。要求第三方应用必须有服务器。对安全性要求较高,web项目中一般使用授权码模式。
2. 简化模式:流程简单;适用于纯前端应用,不安全。Token有效期短,浏览器关闭即失效
3. 密码模式:需要输入账号密码,极度不安全,需要高度信任第三方应用
适用于其他授权模式都无法采用的情况;原生APP可以使用,web不建议使用
4. 客户端模式:授权维度为应用维度,而不是用户维度。因此有可能多个用户共用一个Token的情况。适用于应用维度的共享资源。适用于服务器之间交互,不需要用户参与。
二.SSO单点登录原理
1.登录
- 用户访问系统1的受保护资源,系统1发现用户未登录,跳转至sso认证中心,并将自己的地址作为参数
- sso认证中心发现用户未登录,将用户引导至登录页面
- 用户输入用户名密码提交登录申请
- sso认证中心校验用户信息,创建用户与sso认证中心之间的会话,称为全局会话,同时创建授权令牌
- sso认证中心带着令牌跳转会最初的请求地址(系统1)
- 系统1拿到令牌,去sso认证中心校验令牌是否有效
- sso认证中心校验令牌,返回有效,注册系统1
- 系统1使用该令牌创建与用户的会话,称为局部会话,返回受保护资源
- 用户访问系统2的受保护资源
- 系统2发现用户未登录,跳转至sso认证中心,并将自己的地址作为参数
- sso认证中心发现用户已登录,跳转回系统2的地址,并附上令牌
- 系统2拿到令牌,去sso认证中心校验令牌是否有效
- sso认证中心校验令牌,返回有效,注册系统2
- 系统2使用该令牌创建与用户的局部会话,返回受保护资源
用户登录成功之后,会与sso认证中心及各个子系统建立会话,用户与sso认证中心建立的会话称为全局会话,用户与各个子系统建立的会话称为局部会话,局部会话建立之后,用户访问子系统受保护资源将不再通过sso认证中心,全局会话与局部会话有如下约束关系
- 局部会话存在,全局会话一定存在
- 全局会话存在,局部会话不一定存在
- 全局会话销毁,局部会话必须销毁
2.注销
- 用户向系统1发起注销请求
- 系统1根据用户与系统1建立的会话id拿到令牌,向sso认证中心发起注销请求
- sso认证中心校验令牌有效,销毁全局会话,同时取出所有用此令牌注册的系统地址
- sso认证中心向所有注册系统发起注销请求
- 各注册系统接收sso认证中心的注销请求,销毁局部会话
- sso认证中心引导用户至登录页面
参考链接:
OAuth2的四种模式
OAuth2.0-阮一峰
SSO单点登录原理