OAuth2

时间 2019-11-07

标签 oauth2 oauth 繁體版

原文原文链接

OAuth是一个关于受权（authorization）的开放网络标准，在全世界获得普遍应用，目前的版本是2.0版。express

本文对OAuth 2.0的设计思路和运行流程，作一个简明通俗的解释，主要参考材料为RFC 6749。json

一应用场景

为了理解OAuth的适用场合，让我举一个假设的例子。浏览器

有一个"云冲印"的网站，能够将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让"云冲印"读取本身储存在Google上的照片。缓存

问题是只有获得用户的受权，Google才会赞成"云冲印"读取这些照片。那么，"云冲印"怎样得到用户的受权呢？安全

传统方法是，用户将本身的Google用户名和密码，告诉"云冲印"，后者就能够读取用户的照片了。这样的作法有如下几个严重的缺点。服务器

（1）"云冲印"为了后续的服务，会保存用户的密码，这样很不安全。

（2）Google不得不部署密码登陆，而咱们知道，单纯的密码登陆并不安全。

（3）"云冲印"拥有了获取用户储存在Google全部资料的权力，用户无法限制"云冲印"得到受权的范围和有效期。

（4）用户只有修改密码，才能收回赋予"云冲印"的权力。可是这样作，会使得其余全部得到用户受权的第三方应用程序所有失     效。

（5）只要有一个第三方应用程序被破解，就会致使用户密码泄漏，以及全部被密码保护的数据泄漏。

OAuth就是为了解决上面这些问题而诞生的。网络

二名词定义

在详细讲解OAuth 2.0以前，须要了解几个专用名词。它们对读懂后面的讲解，尤为是几张图，相当重要。app

（1）Third-party application：第三方应用程序，本文中又称"客户端"（client），即上一节例子中的"云冲印"。An application making protected resource requests on behalf of the resource owner and with its authorization.  The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices)
（2）HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上一节例子中的Google。
（3）Resource Owner：资源全部者，本文中又称"用户"（user）。
     An entity capable of granting access to a protected resource. When the resource  owner is a person, it is referred to as an end-user
（4）User Agent：用户代理，本文中就是指浏览器。
（5）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
    The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization
（6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，能够是同一台服务器，也能够是不一样的服务器。
    The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

知道了上面这些名词，就不难理解，OAuth的做用就是让"客户端"安全可控地获取"用户"的受权，与"服务商提供商"进行互动。框架

三 OAuth的思路

OAuth在"客户端"与"服务提供商"之间，设置了一个受权层（authorization layer）。"客户端"不能直接登陆"服务提供商"，只能登陆受权层，以此将用户与客户端区分开来。"客户端"登陆受权层所用的令牌（token），与用户的密码不一样。用户能够在登陆的时候，指定受权层令牌的权限范围和有效期。网站

"客户端"登陆受权层之后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。

运行流程

OAuth 2.0的运行流程以下图，摘自RFC 6749。

（A）用户打开客户端之后，客户端要求用户给予受权。（The client requests authorization from the resource     owner.  The authorization request can be made directly to the resource owner(as shown), or     preferably indirectly via the authorizationserver as an intermediary.）

（B）用户赞成给予客户端受权。(The client receives an authorization grant, which is acredential         representing the resource owner's authorization,expressed using one of four grant types       defined in this specification or using an extension grant type.  The authorization grant       type depends on the method used by the client to request authorization and the types           supported by the authorization server)

（C）客户端使用上一步得到的受权，向认证服务器申请令牌。
     The client requests an access token by authenticating with the
     authorization server and presenting the authorization grant
（D）认证服务器对客户端进行认证之后，确认无误，赞成发放令牌。
    The authorization server authenticates the client and validates
    the authorization grant, and if valid, issues an access token
（E）客户端使用令牌，向资源服务器申请获取资源。
		The client requests the protected resource from the resource
    server and authenticates by presenting the access token
（F）资源服务器确认令牌无误，赞成向客户端开放资源。
		The resource server validates the access token, and if valid,
    serves the request

四客户端的受权模式(Authorization Grant)

客户端必须获得用户的受权（authorization grant），才能得到令牌（access token）。OAuth 2.0定义了四种受权方式

受权码模式（authorization code）
简化模式（implicit）
密码模式（resource owner password credentials）
客户端模式（client credentials）

受权码模式（authorization code）

受权码模式（authorization code）是功能最完整、流程最严密的受权模式。它的特色就是经过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

它的步骤以下：

（A）用户访问客户端，后者将前者导向认证服务器。

（B）用户选择是否给予客户端受权。

（C）假设用户给予受权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个受权码。

（D）客户端收到受权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了受权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

下面是上面这些步骤所须要的参数。

A步骤中，客户端申请认证的URI，包含如下参数：

response_type：表示受权类型，必选项，此处的值固定为"code"
client_id：表示客户端的ID，必选项
redirect_uri：表示重定向URI，可选项
scope：表示申请的权限范围，可选项
state：表示客户端的当前状态，能够指定任意值，认证服务器会原封不动地返回这个值。

下面是一个例子。

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

C步骤中，服务器回应客户端的URI，包含如下参数：

code：表示受权码，必选项。该码的有效期应该很短，一般设为10分钟，客户端只能使用该码一次，不然会被受权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
state：若是客户端的请求中包含这个参数，认证服务器的回应也必须如出一辙包含这个参数。

下面是一个例子。

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含如下参数：

grant_type：表示使用的受权模式，必选项，此处的值固定为"authorization_code"。
code：表示上一步得到的受权码，必选项。
redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
client_id：表示客户端ID，必选项。

下面是一个例子。

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

E步骤中，认证服务器发送的HTTP回复，包含如下参数：

access_token：表示访问令牌，必选项。
token_type：表示令牌类型，该值大小写不敏感，必选项，能够是bearer类型或mac类型。
expires_in：表示过时时间，单位为秒。若是省略该参数，必须其余方式设置过时时间。
refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
scope：表示权限范围，若是与客户端申请的范围一致，此项可省略。

下面是一个例子。

HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

从上面代码能够看到，相关参数使用JSON格式发送（Content-Type: application/json）。此外，HTTP头信息中明确指定不得缓存。

简化模式

简化模式（implicit grant type）不经过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"受权码"这个步骤，所以得名。全部步骤在浏览器中完成，令牌对访问者是可见的，且客户端不须要认证。

它的步骤以下：

（A）客户端将用户导向认证服务器。

（B）用户决定是否给于客户端受权。

（C）假设用户给予受权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。

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

（E）资源服务器返回一个网页，其中包含的代码能够获取Hash值中的令牌。

（F）浏览器执行上一步得到的脚本，提取出令牌。

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

下面是上面这些步骤所须要的参数。

A步骤中，客户端发出的HTTP请求，包含如下参数：

response_type：表示受权类型，此处的值固定为"token"，必选项。
client_id：表示客户端的ID，必选项。
redirect_uri：表示重定向的URI，可选项。
scope：表示权限范围，可选项。
state：表示客户端的当前状态，能够指定任意值，认证服务器会原封不动地返回这个值。

下面是一个例子。

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

C步骤中，认证服务器回应客户端的URI，包含如下参数：

access_token：表示访问令牌，必选项。
token_type：表示令牌类型，该值大小写不敏感，必选项。
expires_in：表示过时时间，单位为秒。若是省略该参数，必须其余方式设置过时时间。
scope：表示权限范围，若是与客户端申请的范围一致，此项可省略。
state：若是客户端的请求中包含这个参数，认证服务器的回应也必须如出一辙包含这个参数。

下面是一个例子。

HTTP/1.1 302 Found
     Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
               &state=xyz&token_type=example&expires_in=3600

在上面的例子中，认证服务器用HTTP头信息的Location栏，指定浏览器重定向的网址。注意，在这个网址的Hash部分包含了令牌。

根据上面的D步骤，下一步浏览器会访问Location指定的网址，可是Hash部分不会发送。接下来的E步骤，服务提供商的资源服务器发送过来的代码，会提取出Hash中的令牌。

密码模式

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供本身的用户名和密码。客户端使用这些信息，向"服务商提供商"索要受权。

在这种模式中，用户必须把本身的密码给客户端，可是客户端不得储存密码。这一般用在用户对客户端高度信任的状况下，好比客户端是操做系统的一部分，或者由一个著名公司出品。而认证服务器只有在其余受权模式没法执行的状况下，才能考虑使用这种模式。

它的步骤以下：

（A）用户向客户端提供用户名和密码。

（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。

（C）认证服务器确认无误后，向客户端提供访问令牌。

B步骤中，客户端发出的HTTP请求，包含如下参数：

grant_type：表示受权类型，此处的值固定为"password"，必选项。
username：表示用户名，必选项。
password：表示用户的密码，必选项。
scope：表示权限范围，可选项。

下面是一个例子。

POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=password&username=johndoe&password=A3ddj3w

C步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。

HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

上面代码中，各个参数的含义参见《受权码模式》一节。

整个过程当中，客户端不得保存用户的密码。

客户端模式

客户端模式（Client Credentials Grant）指客户端以本身的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以本身的名义要求"服务提供商"提供服务，其实不存在受权问题。

它的步骤以下：

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

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

A步骤中，客户端发出的HTTP请求，包含如下参数：

grant_type：表示受权类型，此处的值固定为"client_credentials"，必选项。
scope：表示权限范围，可选项。

POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=client_credentials

认证服务器必须以某种方式，验证客户端身份。

B步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。

HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "example_parameter":"example_value"
     }

上面代码中，各个参数的含义参见《受权码模式》一节。

更新令牌

若是用户访问的时候，客户端的"访问令牌"已通过期，则须要使用"更新令牌"申请一个新的访问令牌。

客户端发出更新令牌的HTTP请求，包含如下参数：

grant_type：表示使用的受权模式，此处的值固定为"refresh_token"，必选项。
refresh_token：表示早前收到的更新令牌，必选项。
scope：表示申请的受权范围，不能够超出上一次申请的范围，若是省略该参数，则表示与上一次一致。

下面是一个例子。

POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

1. OAUth2
2. oauth2
3. OAuth2
4. oauth2+JWT实现oauth2服务
5. 01-OAuth2
6. SpringSecurity Oauth2
7. springcloud-oauth2
8. spring oauth2
9. 使用 OAuth2-Server-php 搭建 OAuth2 Server
10. Spring Security Oauth2 自定义 OAuth2 Exception
更多相关文章...

OAuth2

一 应用场景

二 名词定义

三 OAuth的思路

运行流程

四 客户端的受权模式(Authorization Grant)

受权码模式（authorization code）

简化模式

密码模式

客户端模式

更新令牌

一应用场景

二名词定义

四客户端的受权模式(Authorization Grant)