OAuth2.0 协议入门指南

朴灿烈づ我的快乐病毒、 2022-05-16 12:37 304阅读 0赞

> 本文希望以应用场景的角度出发，帮助大家快随了解OAuth协议流程，更为清楚明白的介绍在各种情况使用什么授权模式更为合适。  
> [OAuth2 官网][OAuth2]  
> [原文地址][Link 1]  
> 本系列相关文章：  
> [OpenID Connect 协议入门指南][OpenID Connect]  
> [SAML2.0入门指南][SAML2.0]

# 1. 协议中各种角色：应用、API和用户 #

*第三方应用：客户端*  
客户端，即尝试去获得用户账号信息的应用，用户需要先对此操作授权。

*API: 资源服务器*  
即资源服务器，提供用来获得用户信息的API。

*授权服务器*  
授权服务器用来提供接口，让用户同意或者拒接访问请求。在某些情况下，授权服务器和API资源服务器会是同一个，但是在大多数情况下，二者是独立的。

*用户：资源的拥有者*  
资源的拥有者，当前的请求正在尝试获得他们账户的部分信息。

# 2. 创建App #

在开始OAuth流程之前，你首选需要注册一个新应用到服务器。通常在注册的过程中，需要提供应用的基本信息，比如应用名称、网站信息、logo等等。此外，你还需要注册一个**重定向URI**，用以将用户通过浏览器或者移动客户端重定向回Web服务器，*这个URI很重要，在后面的我们会具体讲到*。

## 2.1 重定向URI ##

服务器只会把用户重定向回注册过的URI以避免一些安全攻击。任何HTTP的从定向请求都必须使用TLS保护，所以要求使用*HTTPS*。这样的要求是为了防止token在传输的过程中被截获。对于原生APP，重定向的URI可以被注册为一个自定义的URL scheme，比如

> [demoapp://redirect][demoapp_redirect]

## 2.2 Client ID & Secret ##

当注册完毕之后，一般会返回给用户一个客户端ID(**Client ID**)和一个客户端密钥（**Client Secret**）。这个ID一般是公开的信息，用来构造登录URL，或者被包含在页面的JS代码中。这个密钥（Secret） **必须是**保密的。如果一个已经部署的应用不能保护密钥，比如一个简单的JS网页，则不应该使用客户端密钥，同时理论上服务器也不应该向这类应用颁发密钥。

# 3. 授权：得到授权码 #

OAuth 2流程的第一步是获得用户的授权。对于基于浏览器应用或是移动应用，这一步通常是在服务器显示给用户的接口上完成。

OAuth 2提供了多种授权模式（*grant types*），根据不同的情况而使用。

*  授权码模式：适用于Web应用、浏览器应用或是移动APP;
 *  口令模式：适用于使用用户名和口令登录的模式；
 *  应用访问模式：适用于应用访问；
 *  默认模式：之前被推荐在没有Secret情况下使用，现在被没有客户端密钥的授权码模式取代。

每一个模式的使用细节将在下面的章节中说明。

## 3.1 Web服务 ##

Web服务是最常见的应用类型。用户所使用的Web App程序运行在服务器端，其源码不会公开暴露，这就代表着这类应用在授权的过程中可以使用客户端密钥（Client Secret），以避免某些攻击手段。

### 3.1.1 授权 ###

创建登录链接，将用户重定向到授权服务器：

https://oauth2server.com/auth?response_type=code&
     client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=1234zyx

*  **code**: 代表服务器希望收到授权码；
 *  **client\_id**: 注册应用时颁发的ID；
 *  **redirect\_uri**: 指明当用户授权完成之后返回的地址；
 *  **scope**: 一个或多个值，用来指明希望获得用户账户哪部分权限；
 *  **state**：由应用生成的一个随机字符串，会在稍后的过程中去验证。

通过以上的链接，用户将会看到如下的界面

![Image 1][]

image.png

当用户点击“Allow”之后，授权服务器会把用户重定向回应用网站，并在链接中带上授权码：

https://oauth2client.com/cb?code=AUTH_CODE_HERE&state=1234zyx

*  code: 服务器返回的授权码；
 *  state: 返回请求授权码过程中发送的state;

当应有接收到这个请求时，要首先验证state是否就是应用刚才发送的值。在发送state之后，可以把state保存到Session以便于后续的比较。这样做的目的是防止应用接受任意伪造的授权码。

### 3.1.2 换取Token ###

然后使用授权码到资源服务器换取Token：

POST https://api.oauth2server.com/token
      grant_type=authorization_code&
      code=AUTH_CODE_HERE&
      redirect_uri=REDIRECT_URI&
      client_id=CLIENT_ID&
      client_secret=CLIENT_SECRET

*  **grant\_type=authorization\_code** \- 代表授权模式为验证码；
 *  **code=AUTH\_CODE\_HERE** \- 验证码；
 *  **redirect\_uri=REDIRECT\_URI** \- 重定向URI；
 *  \*\*client\_id=CLIENT\_ID \*\*- 注册应用时颁发的ID；
 *  **client\_secret=CLIENT\_SECRET** \- 客户端密钥，因为当前请求时服务器之间传输的，并没有暴露给用户。

API服务器会返回授权码和其有效期：

{
      "access_token":"RsT5OjbzRn430zqMLgV3Ia",
      "expires_in":3600
    }

或者是授权失败的提示：

{
      "error":"invalid_request"
    }

> 安全性提示：服务器要求应用必须提前注册从定向URI

## 3.2 纯页面应用 ##

纯页面应用，也称为浏览器应用，其所有运行代码都会加载到本地的浏览器上。因此其代码会暴露给使用者的浏览器，不能保护客户端密钥的安全，所以客户端密钥不能在这种情况下使用，除此之外其和Web应用没有太大区别。

> 以前，曾经推荐使用*默认模式（implicit type）*，该种模式将会直接返回token，并不使用授权码来换取token。但是到了本文编写之时，业界已经开始转为推荐使用没有Scret的授权码流程，这样这样协议流程更为安全，具体内容请见引文: [Redhat][], [Deutsche Telekom][], [Smart Health IT][].

### 3.2.1 授权 ###

创建登录链接，将用户发送至授权服务器：

https://oauth2server.com/auth?response_type=code&
    client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=1234zyx

*  **code** \- 指明使用授权码模式；
 *  **client\_id** \- 注册时颁发的client ID；
 *  **redirect\_uri** \- 重定向URI，代表当授权完成之后，返回的路径；
 *  **scope** \- 一个或多个值，代表所希望访问当前用户的那部分信息；
 *  **state** \- 由于后续步骤验证实用的随机字符串。  
    之后，同样用户会显示授权页面：
    
    ![Image 1][]
    
    image.png
    
      
    当用户点击“Allow”，授权服务器依据重定向URI将用户返回到应用网站：

https://oauth2client.com/cb?code=AUTH_CODE_HERE&state=1234zyx

*  **code** \- 授权服务器返回的授权码；
 *  **state** \- 登录请求中发出的随机码；

应有服务器收到该请求之后，应该先核对*state*的值，以避免接受伪造的授权码；

### 3.2.2 换取Token ###

POST https://api.oauth2server.com/token
      grant_type=authorization_code&
      code=AUTH_CODE_HERE&
      redirect_uri=REDIRECT_URI&
      client_id=CLIENT_ID

## 3.3 移动APP ##

> 以前，曾经推荐使用*默认模式（implicit type）*，该种模式将会直接返回token，并不使用授权码来换取token。但是到了本文编写之时，业界已经开始转为推荐使用没有Scret的授权码流程，这样这样协议流程更为安全，

类似于纯页面应用，移动应用不能包含客户端密钥，所以使用的是没有客户端密钥的Oauth流程。此外，对于移动APP，还有一些特别地方需要注意。

### 3.3.1 授权 ###

创建一个登陆按钮，将用户跳转到服务器在手机上原生APP，或是通过手机的浏览器跳转到服务器Web页面、无论是IOS还是Android，都可以通过URL Scheme协议启动本地APP；

3.3.1.1 使用服务器的APP

如果用户安装了服务器的原生APP，比如微博APP或是微信APP，可以通过URL来直接启动APP：

fbauth2://authorize?response_type=code&client_id=CLIENT_ID
      &redirect_uri=REDIRECT_URI&scope=email&state=1234zyx

对于还要支持[PKCE extension][]的服务器，还需要创建一个随机字符串("*code verifier*")保存本地，然后再URL中追加如下参数：

*  **code\_challenge=XXXXXXX** \- 过base64编码后的"code verifier"的Hash值；
 *  **code\_challenge\_method=S256** \- 指明Hash算法种类，这里是sha256；

需要说明的是，这里的URL用的协议App提前向操作系统定义好的。

3.3.1.2 使用手机Web浏览器

如果服务器在手机上没有一个原生的APP，也可以通过手机浏览器上来走标准的Web认证流程。这里需要注意的是，不要使用应用内置的WebView，因为这样就不无法保证用户正在登陆网站是不是伪造的。

一般是使用移动端的原生浏览器，对于IOS 9+版本的用户，可以使用“SafariViewController”在应用中启动嵌入浏览器，这个API会显示地址栏让用户判断是否打开正确的网页，同时还提供和*Safari*浏览器共享cookie的功能。该API能保证应用被注入和修改，所以可以被认为是安全的。对于Android开发者，可以考虑使用Chrome Custom Tabs来提供类似的功能。

https://facebook.com/dialog/oauth?response_type=code&client_id=CLIENT_ID
     &redirect_uri=REDIRECT_URI&scope=email&state=1234zyx

参数的意义和使用服务器原生APP的情况是一样的。比如用户登录FaceBook，就会在手机上看到如下界面：

![Image 1][]

everyday-city-auth.png

### 3.3.2 换取Token ###

当用户点击"*Approve*"之后，用户将会被重定向到应用，同样可以使用URL Scheme:

fb00000000://authorize#code=AUTHORIZATION_CODE&state=1234zyx

应用收到该请求之后，要先比较*state*的值是否满足预期，然后用授权码来换取Token。

换取Token的过程和在Web中请求类似，只不过没有加入*Client Secret*。如果服务器需要支持*PKCE*，则还需要添加更多的参数：

POST https://api.oauth2server.com/token
      grant_type=authorization_code&
      code=AUTH_CODE_HERE&
      redirect_uri=REDIRECT_URI&
      client_id=CLIENT_ID&
      code_verifier=VERIFIER_STRING

*  **grant\_type=authorization\_code** \- 标识这是授权码模式；
 *  **code=AUTH\_CODE\_HERE** \- 授权码；
 *  **redirect\_uri=REDIRECT\_URI** \-重定向URL；
 *  **client\_id=CLIENT\_ID** \- Client ID;
 *  **code\_verifier=VERIFIER\_STRING** \- 之前步骤中，生成的随机字符串

如果服务器支持*PKCE*，则授权服务器需要能“Code-Challenge”中识别code，也就是提供再次对*code\_verifier*进行Hash，并且比较计算出的Hash值和之前的*code\_challenge*是否一致，以此代替*Client Secret*，保证安全性。

## 3.4 其他授权模式 ##

### 3.4.1 口令模式 ###

这种模式直接使用用户名和口令来取回Token。很显然，这要求应用去收集用户的口令，所以只建议当前的APP是专门为服务器设计的情况下使用。比如Twitter的App使用该模式登录。

POST https://api.oauth2server.com/token
      grant_type=password&
      username=USERNAME&
      password=PASSWORD&
      client_id=CLIENT_ID

*  **grant\_type=password** \- 指明使用口令模式；
 *  **username=USERNAME** \- 用户名；
 *  **password=PASSWORD** \- 口令；
 *  **client\_id=CLIENT\_ID** \- client ID；

资源服务器返回的Token和其他模式是一样的。值得注意的是，因为口令模式多用于移动端和桌面应用，*使用Secret并不合适*。

### 3.4.2 应用访问模式 ###

在一些情况下，是应用去访问服务区获取资源，而不是某个用户。比如应用去获取一些服务在应用配置信息，这些信息不属于某个用户的。在这种情形下，应用也需要被授权，得到Token去访问数据，这就是应用访问模式的意义。

OAuth提供了*client\_credentials*模式来结局这个问题：

POST https://api.oauth2server.com/token
        grant_type=client_credentials&
        client_id=CLIENT_ID&
        client_secret=CLIENT_SECRET

资源服务器返回形式和其他模式是相同的。

# 4. 创建已经授权的请求 #

最后就是使用Token获取资源，如何表面一个请求是已经呗授权？就是Http的头中加入Token:

curl -H "Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia" \
    https://api.oauth2server.com/1/me

另外还要确保是使用**HTTPS**通信，这样才能确保信息安全。

# 5. 与OAuth 1.0版本的差异 #

最后说明下两个版本的OAuth协议有什么不同点。

## 5.1 认证和签名 ##

OAuth 1.0 流程中有大量密码学上的签名操作，以保证数据完整性；OAuth 2中有HTTPS来保护数据。

## 5.2 用户体验 ##

和OAuth 1.0相比，OAuth 2在移动端的体验更好。

## 5.3 性能 ##

和OAuth 1.0相比，OAuth 2性能更好，减少了流程的步骤。

# 其他参考 #

Learn more about [creating OAuth 2.0 Servers][]  
[PKCE Extension][PKCE extension]  
[Recommendations for Native Apps][]  
More information is available on [OAuth.net][]  
Some content adapted from [hueniverse.com][].

作者：登高且赋  
链接：https://www.jianshu.com/p/6392420faf99  
來源：简书  
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

[OAuth2]: https://link.jianshu.com?t=https://oauth.net/2/
[Link 1]: https://link.jianshu.com?t=https://aaronparecki.com/oauth-2-simplified/
[OpenID Connect]: https://www.jianshu.com/p/be7cc032a4e9
[SAML2.0]: https://www.jianshu.com/p/636c1ee16eba
[demoapp_redirect]: https://link.jianshu.com?t=demoapp://redirect
[Image 1]: 
[Redhat]: https://link.jianshu.com?t=https://www.ietf.org/mail-archive/web/oauth/current/msg16966.html
[Deutsche Telekom]: https://link.jianshu.com?t=https://www.ietf.org/mail-archive/web/oauth/current/msg16968.html
[Smart Health IT]: https://link.jianshu.com?t=https://www.ietf.org/mail-archive/web/oauth/current/msg16967.html
[PKCE extension]: https://link.jianshu.com?t=https://tools.ietf.org/html/rfc7636
[creating OAuth 2.0 Servers]: https://link.jianshu.com?t=https://www.oauth.com/
[Recommendations for Native Apps]: https://link.jianshu.com?t=https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07
[OAuth.net]: https://link.jianshu.com?t=http://oauth.net/
[hueniverse.com]: https://link.jianshu.com?t=http://hueniverse.com/