浅谈Oauth2.0授权

一、背景

近期公司准备上身份认证平台(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表示"密码式",usernamepassword是 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_idclient_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模式。

流程步骤

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