一、背景

近期公司准备上身份认证平台（IAM），主要有两块内容，一部分是单点登录、一部分是账号生命周期管理。其中涉及几个常用的单点登录标准认证协议，其中有SMAL、LOAP、CAS、OIDC、Oauth2.0，本篇文章对Oauth2.0认证协议进行讲解。

二、Oauth发展史

OAuth的发展史可以分为以下几个阶段：
2007年12月，OAuth 1.0版本发布，并迅速成为工业标准。
2008年6月，发布了OAuth 1.0 Revision A，这是一个稍作修改的修订版本，主要修正了一个安全方面的漏洞。
2010年4月，OAuth 1.0在IETF发布，协议编号RFC 5849。
2010年，发布了OAuth 2.0，这是OAuth协议的下一个版本，该版本与OAuth 1.0不兼容。

OAuth 诞生之初是为了解决 Web 浏览器场景下的授权问题。比如有一个网站A，在新用户注册时是支持QQ账号注册的，如果网站A能拿到QQ昵称和头像作为网站A用户注册的基本资料，这样新注册用户流程就简单多了，很多信息都不需要用户自己填写，直接套用QQ号的信息就可以了。这样的注册模式就对用户很友好，自然很容易提升用户注册的热情。

三、Oauth2.0定义

OAuth 2.0一词中的"Auth"表示"授权Authorization"，字母"O"表示"开放Open"，连在一起就表示"开放授权"。这也是为什么我们使用OAuth的场景，通常发生在开放平台的环境下。首先需要区分下认证和授权：

认证（Authentication）：用来验证某个用户是否具有访问系统的权限。如果认证通过，该用户就可以访问系统，从而创建、修改、删除、查询平台支持的资源。认证的方式就是我们登录，比如账密登录、手机验证码登录等。
授权（Authorization）：用来验证某个用户是否具有访问某个资源的权限，如果授权通过，该用户就能对资源做增删改查等操作。

简单而言，认证就是证明访问者的身份，决定他是否能进入系统；授权则是决定访问者能做哪些内容。一般来说，都是先认证后检查授权。

四、Oauth2.0常用角色

OAuth 2.0 主要有4类角色：

    resource owner：资源所有者，指终端的“用户”（即授权登录中资料信息的拥有者）。
    resource server：资源服务器，即服务提供商存放受保护资源。访问这些资源，需要获得访问令牌（access token）。
    client：客户端，代表向受保护资源进行资源请求的第三方应用程序。
    authorization server：授权服务器，在验证资源所有者并获得授权成功后，将发放访问令牌给客户端。

五、Oauth2.0常用模式

OAuth2.0提供了四种授权(获取令牌)方式，四种方式均采用不同的执行流程，让我们适应不同的场景。

授权码（authorization-code）
隐藏式（implicit）
密码式（password）：
客户端凭证（client credentials）

5.1、授权码（authorization-code）--最广泛

授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

重要步骤说明：

第一步，A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。

https://b.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

上面 URL 中，response_type参数表示要求返回授权码（code），client_id参数让 B 知道是谁在请求，redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是只读）。

第二步，用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。下面 URL 中，code参数就是授权码。

https://a.com/callback?code=AUTHORIZATION_CODE

第三步，A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。

https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL

上面 URL 中，client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址。

第四步，B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。

{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

上面 JSON 数据中，access_token字段就是令牌，A 网站在后端拿到了。

5.2、隐藏式（implicit）

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

第一步，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。下面 URL 中，response_type参数为token，表示要求直接返回令牌。

https://b.com/oauth/authorize?
  response_type=token&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

第二步，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。下面 URL 中，token参数就是令牌，A 网站因此直接在前端拿到令牌。

https://a.com/callback#token=ACCESS_TOKEN

5.3、密码式（password）

如果高度信任第三方应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌。下面 URL 中，grant_type参数是授权方式，这里的password表示"密码式"，username和password是 B 的用户名和密码。

https://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

第二步，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。

5.4、客户端凭证（client credentials）

client credentials通常适用于没有前端的命令行应用。例如系统之间的接口交互认证，例如：适用于A系统请求B系统的后端需要认证场景。这种方式给出的令牌，是针对第三方应用的，而不是针对用户的。

第一步，A 应用在命令行向 B 发出请求。下面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让 B 确认 A 的身份。

https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

第二步，B 网站验证通过以后，直接返回令牌。

{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

六、Oauth2.0最佳实践(授权码模式)

让我们看下业界标杆微信开放平台是怎么做开放授权的。网站应用微信登录是基于OAuth2.0协议标准构建的微信OAuth2.0授权登录系统，微信OAuth2.0授权登录目前支持authorization_code模式。

流程步骤：

网站A需要在微信开放平台注册，填写回调地址，并获得相应的 AppID 和AppSecret。
用户登录了网站A，获得了网站A的登录态，这里用JWT来维护登录态。
此时网站A需要访问用户的微信相关资源，这里需要获得用户的微信授权。网站A弹出一个页面引导用户去微信开放平台的网站来授权。
用户点击【去授权】，浏览器跳转到微信二维码界面。
此时微信用户尚未在web端登录，因此需要微信用户【扫码登录】，登录成功后浏览器带着AppID请求微信开放平台，请求授权给网站A。
微信开放平台同意后返回页面让微信用户确认：网站A将获取以下权限：1. ... 2. ...，是否同意授权。
点击【同意授权】，用户浏览器就带着AppID和重定向URI两个参数去请求微信开放平台的授权服务器。重定向URI是网站A的地址。
微信开放平台的授权服务器收到请求，通过AppID知道了这个是要微信用户要给网站A授权，因此生成了一个授权码CODE，以重定向的方式返回给微信用户，重定向的地址填的是第7步请求带上来的URI，并参数带上这个CODE。
微信用户收到重定向的回复后，拿出重定向URI和CODE，重定向跳转到这个URI，并参数带上这个CODE。因为跳转的网址是网站A的域名地址，因为用户已经在该网站登录了，因此这个请求会带上登录态的JWT。
网站A收到微信用户CODE后，从JWT中解析出这个请求的来源用户的uid，这样网站用户uid就跟CODE有了绑定关系。接着拿出自己的AppID 和AppSecret，跟CODE一起请求微信开放平台授权服务器。
微信开放平台授权服务器收到AppID + AppSecre + CODE 三个参数后，生成access_token、refresh_token，返回这些token给网站A。
网站A拿到access_token后就存储起来，有了uid->access_token的映射关系。后续带着这个access_token就可以访问微信用户的指定资源了，无需每次要微信用户登录和授权。

七、Oauth2.0令牌使用和更新

7.1、令牌使用

A 网站拿到令牌以后，就可以向 B 网站的 API 请求数据了。每个发到 API 的请求，都必须带有令牌。具体做法是在请求的头信息，加上一个Authorization字段，令牌就放在这个字段里面。下面命令中，ACCESS_TOKEN就是拿到的令牌。

curl -H "Authorization: Bearer ACCESS_TOKEN"

"https://api.b.com"

7.2、更新令牌

令牌的有效期到了，如果让用户重新走一遍上面的流程，再申请一个新的令牌，很可能体验不好，而且也没有必要。OAuth 2.0 允许用户自动更新令牌。具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。

https://b.com/oauth/token?
  grant_type=refresh_token&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET&
  refresh_token=REFRESH_TOKEN

上面 URL 中，grant_type参数为refresh_token表示要求更新令牌，client_id参数和client_secret参数用于确认身份，refresh_token参数就是用于更新令牌的令牌。 B 网站验证通过以后，就会颁发新的令牌。

refresh_token拥有较长的有效期（30天），当refresh_token失效后，需要用户重新授权。因为access_token是需要频繁在网络上传输的，因此被窃取的风险大，所access_token的有效时间设置较短；refresh_token仅仅在续签access_token时会在网络上传输，被窃取的风险相对小点，因此refresh_token拥有较长的有效期。这样一长一短的双token机制会比较安全。

双Token机制更为安全，而且可以很好的处理在线、离线续签的问题，可以参考这个回答深入理解双Token机制。如下图：