Oauth2 简介

包括:

一. OAuth 概念

二. OAuth 运行流程

三. OAuth 授权模式


一. OAuth 概念

        OAuth 是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而不需要将用户名和密码提供给第三方应用。OAuth允许用户提供一个令牌,而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站在特定的时段内访问特定的资源。这样,OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息,而非所有内容。


二.OAuth 运行流程

首先会有几个术语:

  • Resource owner : 资源所有者,本文中称为 “用户”。
  • Authorization server :认证服务器,即服务提供商专门用来处理认证的服务器。
  • Resource server:资源服务器,即用户提供商存放用户生成的资源的服务器。它和认证服务器,可以是同一台服务器,也可以是不同的服务器。
总的来说, 认证服务器 和 资源服务器 都由 服务提供商 提供。

流程如下图1:

图1
文字解释:

  1. A  用户打开客户端以后,客户端要求用户给予授权。
  2. B  用户同意给予客户端授权。
  3. C  客户端使用上一步获得的授权,向认证服务器申请令牌。
  4. D  认证服务器对客户端进行认证后,确认无误后,同意发放令牌。
  5. E  客户端使用令牌,向资源服务器申请获取资源。
  6. F  资源服务器确认令牌无误后,同意向客户端开放资源。
上面的 6 个步骤中,重点在于 2 ,即用户怎么给客户端授权,有了这个授权,客户端就可以获取令牌,进而凭借令牌获取资源。


三. OAuth 授权模式
OAuth2.0 定义了 四种授权模式。分别为:
  • 授权码模式
  • 简化模式
  • 密码模式
  • 客户端模式

3.1 授权码 模式
        授权码模式是功能最完整,流程最严密的授权模式。它的特定就是通过客户端的后台服务器,与“服务提供商”的认证服务器进行互动。
流程如下图2:

图2

解释:
A  用户访问客户端,后者将前者导向认证服务器。如:
https://www.example.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read
  • www.example.com/v1/oauth/authorize :API 授权的终端。
  • client_id :应用程序的client ID,用于 API 识别应用程序。
  • redirect_uri :获得授权码之后,服务提供商重定向用户代理(比如浏览器)的地址。
  • response_type : 表明授权类型,默认是 code。即授权码模式。
  • scope: 应用程序可以获得的授权级别,默认值为 read。
  • state:表示客户端的当前状态,可以指定任意值,认证服务器会原封不动地返回这个值,用于抵御CSRF 攻击。

B  用户选择是否给予授权。如下图3:

图3

C  假如用户给予授权,认证服务器将用户导向客户端事先指定的 “重定向URL” ,同时附上一个授权码。
https://www.jianshu.com/callback?code=AUTHORIZATION_CODE

D  客户端收到授权码,附上之前的 “重定向URI” 向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的,对用户不可见。
https://www.example.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL
URI 包括:
  • www.example.com/v1/oauth/authorize :API Token的终端。
  • client_id :即 app key / consumer key ,用于验证应用程序。
  • client_secret:即 app secret / consumer secret 用于验证应用程序。
  • grant_type :刚刚获得的授权码
  • redirect_uri :重定向URI,和第一步一致。


E  认证服务器核对了授权码 和 重定向 URI 确认无误后,向客户端发送访问令牌和 更新令牌。
{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read"}

包括了:
  • access_token:访问令牌
  • token_type :令牌类型
  • expires_in :过期时间,单位为秒
  • refresh_token: 更新令牌,用来获取下一次的访问令牌。
  • scope:权限范围。

Ps:
用如下淘宝的一个时序图4表示:

图4

3.2 简化模式
        简化模式不经过第三方应用程序的服务器,直接在浏览器中向认证服务器 申请令牌,跳过了“授权码” 这个步骤,所以步骤都在浏览器中完成,令牌对访问者是可见的,而且客户端不需要认证。这种模式一般是用于客户端应用程序,比如手机应用,桌面客户端应用程序和运行于浏览器上的Web应用程序。授权令牌会交给用户代理,再由用户代理交给应用程序。如下图5:


图5


A 用户访问客户端,客户端将用户导向认证服务器。
https://www.example.com/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

B 用户选择是否给予客户端授权。如下图6:

图6


C 假如用户给予授权,认证服务器将用户导向客户端事先指定的 “重定向URI” ,并且在 URI 的 hash 部分包含了访问令牌。
https://www.example.com/callback#token=ACCESS_TOKEN

D 浏览器向资源服务器发出请求,其中不包括上一步收到的 hash 值。

E 资源服务器返回一个网页,其中包含的代码可以获取Hash 值中的令牌。

F 浏览器执行上一步获得的脚本,提出令牌。

G 浏览器将令牌发送给客户端。

3.3 密码模式
        即用户向客户端提供用户名密码。客户端使用这些信息,向 “服务商提供商” 索要授权。在这种模式下,客户端不得存储密码。这通常用在用户对客户端高度可信的情况下。一般,认证服务器只有在其他授权模式无法执行的情况下,才能考虑使用这种模式。如下图7:

图7
1. A 用户向客户端提供用户名,密码。
2. B 客户端用用户名,密码发送给认证服务器,向后者申请令牌。
3. C 认证服务器确认无误后,向客户端提供访问令牌。

3.4 客户端模式
        客户端使用自己的名义,而不是用户的名义,向“服务提供商” 进行认证。严格来说,客户端模式并不属于OAuth 框架所需要解决的问题。在这种模式下,用户直接向客户端注册,客户端以自己的名义要求“服务提供商”提供服务,其实并不存在授权。图下图5:

图5

A 客户端向认证服务器进行身份认证,并且要求一个访问令牌。

B 认证服务器认证无误后,向客户端提供访问令牌。

        对于这种方式,试用在 访问一些和用户无关的Open Api,比如一些首页数据,这些数据和用户无关,但是又不想任何人都可以调用这个WebApi,那么就可以采用这种模式。





参考:



评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值