OAuth2是一个关于授权(authorization)的开放网络标准
Oauth2 是指一个应用得到用户的另一个应用
Oauth2 需要理解的名词:
-
Third-party application:第三方应用程序,本文中又称"客户端"(client) 及上面说的App
-
HTTP service:HTTP服务提供商,本文中简称"服务提供商",即上一节例子中的QQ。
-
Resource Owner:资源所有者,本文中又称"用户"(user)。
-
User Agent:用户代理,本文中就是指浏览器。
-
Authorization server:认证服务器,即服务提供商专门用来处理认证的服务器。
-
Resource server:资源服务器,即服务提供商存放用户生成的资源的服务器。它与认证服务器,可以是同一台服务器,也可以是不同的服务器
Oauth2 调用大致流程
App | ------》 | 授权服务器 | -------》 | 服务提供商 |
| 登陆到 |
| 通过授权权限登陆到服务提供商 | ↓ |
得到用户许可的服务 | 《------- | 《------------ | 《----------------- | 服务提供商根据授权范围提供服务 |
(A) 用户打开客户端以后,客户端要求用户给予授权。
(B)用户同意给予客户端授权。
(C)客户端使用上一步获得的授权,向认证服务器申请令牌。
(D)认证服务器对客户端进行认证以后,确认无误,同意发放令牌。
(E)客户端使用令牌,向资源服务器申请获取资源。
(F)资源服务器确认令牌无误,同意向客户端开放资源。
客户端必须得到用户的授权(authorization grant),才能获得令牌(access token)
OAuth 2.0定义了四种授权方式:【也可根据自身业务定义自己的模式】
授权码模式(authorization code)
简化模式(implicit)
密码模式(resource owner password credentials)
客户端模式(client credentials)
授权码模式
授权码模式(authorization code)是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器,与"服务提供商"的认证服务器进行互动
密码模式:
密码模式(Resource Owner Password Credentials Grant)中,用户向客户端提供自己的用户名和密码。客户端使用这些信息,向"服务商提供商"索要授权。在这种模式中,用户必须把自己的密码给客户端,但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下,比如客户端是操作系统的一部分,或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下,才能考虑使用这种模式。
客户端模式
客户端模式(Client Credentials Grant)指客户端以自己的名义,而不是以用户的名义,向"服务提供商"进行认证。严格地说,客户端模式并不属于OAuth框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求"服务提供商"提供服务,其实不存在授权问题。
更新令牌
如果用户访问的时候,客户端的"访问令牌"已经过期,则需要使用"更新令牌"申请一个新的访问令牌。
第三方登陆,实质是指OAuth授权,用户想要登陆A网站,A网站让用户提供三方网站的数据,证明自己的身份。获取第三方网站的身份数据,需要OAuth授权。
三方登陆大致流程:
A 网站允许 GitHub 登录,背后就是下面的流程。
- A 网站让用户跳转到 GitHub。
- GitHub 要求用户登录,然后询问"A 网站要求获得 xx 权限,你是否同意?"
- 用户同意,GitHub 就会重定向回 A 网站,同时发回一个授权码。
- A 网站使用授权码,向 GitHub 请求令牌。
- GitHub 返回令牌.
- A 网站使用令牌,向 GitHub 请求用户数据。
用户在点击使用 github登陆之后,就会转跳到GitHub登陆页去,这个转跳连接中携带了,请求第三登陆的客服端id,以及回调地址URL
当用户登陆了github之后会提示是否授权该客服端,这时候如果选择是
将会回调到之前的URL 上去,并携带一个 授权码到第三方客服端,第三方客服端再获得授权码之后,通过授权码 发起请求取得令牌,
请求中需要携带,客服端id,客服端的密钥,以及授权码,
github对其进行核对,该客服端是否再系统中登记,授权码是否有效等
验证通过后返回json文件的token令牌
客服端获得令牌之后,就可以调用github的api接口获得用户数据,调用时携带上token令牌进行身份校验即可,