什么是 OAuth 2.0 授权码模式？

原文章 作者：Aaron Parecki

译者：MoCha => 摩卡先生

前言

授权码模式大概是我们所最常见的OAuth 2.0 授权模式。当用户授权给App时，授权码模式就会在网页应用和原生apps中使用到。

本文章是本系列文章中的第一部分，我们将探讨常用的OAuth 2.0 授权模式。如果你想在我们深入之前了解更多有关OAuth 2.0的知识，请查看What the Heck is OAuth?，这篇文章同样能够在Okta开发者博客上找到。

What is an OAuth 2.0 Grant Type? 什么是 OAuth 2.0 授权模式？

在OAuth 2.0 标准中，“授权模式”指的是一种为应用程序获取access token的方式。

OAuth 2.0 定义了好几种授权模式，其中包括“授权码模式”。OAuth 2.0 的扩展同样可以定义一些新的授权模式。

每一种授权模式在对应的一些特殊用例中都有着最佳实践，例如：web app，原生 app，一些无法启动web浏览器的设备，或者是服务器端到服务器端的应用程序。

The Authorization Code Flow 授权码模式的流程

授权码授权模式被用于web应用以及手机app中。与大多数授权模式不同，授权码模式会在一开始就请求应用去启动浏览器来进行一系列操作。更深入点说，授权码模式的流程有以下步骤：

• 应用程序打开浏览器，将用户连接到OAuth的服务端中
• 用户会看到授权提示以及是否同意应用的请求
• 用户被重定向回到应用程序中，同时在请求栏中携带着授权码字符串
• 应用程序为了获取access token而进行交换授权码的操作

Get the User’s Permission 获取用户权限

OAuth 旨在让用户能够授予应用程序特定的受限访问权限。应用程序首先会确定需要请求的权限，之后会将用户传送至对应的浏览器中以获得他们的许可。为了开启授权流程，应用程序会构造类似以下格式的URL，并且通过浏览器进行访问。

https://authorization-server.com/auth
 ?response_type=code
 &client_id=29352915982374239857
 &redirect_uri=https%3A%2F%2Fexample-app.com%2Fcallback
 &scope=create+delete
 &state=xcoiv98y2kd22vusuye3kch

下面是有关请求参数的说明：

• response_type=code告诉授权服务器，应用正在初始化授权流程
• client_id 应用程序的公共标识，将在开发者首次注册应用时获得
• redirect_uri 告诉授权服务器当用户同意应用的请求后应该将用户返回到何处
• scope 一个或多个以空格分隔的字符串，用于指示应用程序请求的权限。在使用具体的OAuth API时，我们将指定所支持作用域。
• state 应用程序将生成一个随机字符串并包含在请求中，我们应该对用户授权应用程序后是否返回相同的值进行检查。这是为了防止 CSRF attacks.

当用户访问此URL时，授权服务器会提示用户，询问他们是否要授权此应用程序的请求。

Redirect Back to the Application 重定向回到应用程序

如果用户同意授权，那么授权服务器将重定向回到指定的redirect_uri ，并且携带着code以及state

例如，用户将重定向回到以下URL：

https://example-app.com/redirect
 ?code=g0ZGZmNjVmOWIjNTk2NTk4ZTYyZGI3
 &state=xcoiv98y2kd22vusuye3kch

state的值将会和应用程序刚初始请求时设置的一样。但应用程序应当检查重定向中的state是否与最初设置的state一致

code是通过授权服务器生成的授权码，授权码相对来说存活时间是短暂的，在依赖OAuth服务的情况下，一般存活在1~10分钟。

Exchange the Authorization Code for an Access Token 为了获取Access Token 进行的授权码交换

我们即将要结束授权的流程啦。现在应用程序有了授权码，我们可以用它来获取Access Token。

应用程序将会通过以下步骤发起POST请求到服务令牌终端：

• grant_type=authorization_code 告诉令牌终端，应用程序正在使用授权码模式。
• code 重定向回来后，应用程序所携带的授权码。
• redirect_uri 与请求授权码时设置的重定向URL一样。有些API不需要该请求参数，所以在使用之前应当仔细查阅想要使用API的文档。
• client_id 应用程序的客户端ID。
• client_secret 应用程序的客户端secret。确保获取到access token是来自该应用程序的，而不是那些有可能拦截授权码的潜藏攻击者。

令牌终端将验证请求中的所有参数，确保授权码不会过期以及客户端ID和客户端secret是匹配的。如果一切的检查顺利，没有问题，那么将会生成一个access token响应回去！

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
 "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
 "token_type":"bearer",
 "expires_in":3600,
 "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
 "scope":"create delete"
}

这就是完整的授权流程啦！现在应用程序有了access token，那么就可以调用相关API进行请求啦。

When to use the Authorization Code Flow 什么时候该使用授权码

在使用web应用或者是手机应用中，授权码模式将是最好的选择。由于授权码模式在获取access token上额外进行了交换授权码的步骤，因此提供了一种隐式授权模式所没有的安全层。

如果你正在手机应用上使用授权码模式，或者无法存储客户端secret的其他任何类型应用程序，那么你应该使用PKCE extension ，它会提供可能拦截授权码的其他攻击的保护。

交换授权码的步骤确保攻击者无法拦截access token，这是因为access token总是通过应用程序与OAuth服务器之间的安全反向通道传输。