如何理解OAuth 2.0 的四种授权模式

导读

我们都知道OAuth是一个关于授权（authorization）的开放网络标准，目前的版本是2.0版。其有四种授权模式，这四种授权模式分别是什么呢？又分别适用于什么场景呢？

场景解读

有一个"云冲印"的网站，可以将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让"云冲印"读取自己储存在Google上的照片。

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

传统方法是，用户将自己的Google用户名和密码，告诉"云冲印"，后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点。

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

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

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

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

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

OAuth 2就是为了解决上述问题而生，通过令牌来代替比如密码等敏感信息来进行授权，而对于不同场景又有不同的方式获得令牌。下面将介绍这四种授权模式：

四种授权模式

2.1 授权码

授权码模式（authorization code）是功能最完整、流程最严密的授权模式。

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

（2）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌：GET /oauth/token?response_type=code&client_id=test&redirect_uri=重定向页面链接。请求成功返回code授权码，一般有效时间是10分钟。

（3）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。POST /oauth/token?grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=重定向页面链接。

案例流程

用户认证，访问如下地址： http://localhost:8080/oauth/authorize?response_type=code&client_id=webapp​​​​​​&redirect_uri=http://www.baidu.com&scope=all

通过认证后，获得授权码： https://www.baidu.com/?code=cYwid0

使用授权码，申请令牌（必须是POST请求）： http://localhost:8080/oauth/token?grant_type=authorization_code&client_id=webapp&client_secret=webapp&redirect_uri=http://www.baidu.com&code=gk2zvK&scope=all

特点及适用场景分析

这种授权模式是最为严格的，适用于不同公司之间的授权。比如使用qq登录网站A，当你使用QQ登录某个小网站A，并不是直接告诉网站A你的QQ账号和密码。因为这种权限太大，你不知道A网站会不会拿着你的账号和密码去干什么，比如说登录你的qq删除好友或者是发广告，这是完全有可能的。而授权码模式，我们只需要在QQ官方登录，不需要告诉A网站我们的用户名和密码，让QQ的认证服务来替我们只授予一部分权限给A网站，比如获得你的昵称和头像就够了。而且这种模式下我们可以同时个多个第三方应用授予权限，并在可以在管理授予给哪个应用的权限什么时候失效。只需要在qq的第三方应用授权统一管理。

2.2 隐藏式

隐藏模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

流程案例

用户认证，使用浏览器访问地址： http://localhost:8080/oauth/authorize?response_type=token&client_id=webapp&redirect_uri=http://www.baidu.com&scope=all

用户授权后，重定向地址直接获得令牌： https://www.baidu.com/#access_token=faf8de95-ce34-4ce6-a130-d753d0742811&token_type=bearer&expires_in=2073

注意：令牌返回的位置是URL锚点，而不是参数部分。因为OAuth2.0允许重定向地址为HTTP协议地址，因此有可能存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，减少了泄漏令牌的风险。

2.3 密码式

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下。

流程案例

客户端通过用户名和密码获取令牌，访问地址（必须为POST请求）： http://localhost:8080/oauth/token?grant_type=password&client_id=webapp&client_secret=webapp&username=user1&password=123456&scope=all

特点及适用场景分析

需要告诉客户端用户名和密码，但是实现比授权码码模式简单，因此这种模式适用于同一个公司的产品，并且客户端不存储密码（只有同一个公司的产品才能保证该客户端不存密码），这样即使是用户的客户端（比如说手机上的app）被破解，账号也不会被盗，最多也只能获得一个权利受限并且有期限的令牌。

2.4 凭证式（客户端授权）

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

客户端授权方式一般适用于访问公共api接口的这种情景。

流程案例

客户端直接获取令牌（必须POST请求）： http://localhost:8080/oauth/token?grant_type=client_credentials&client_id=webapp&client_secret=webapp&scope=all

直接返回令牌，通过令牌即可访问资源

特点及适用场景分析

服务器之间的交互，不需要用户参与，比如百度的OCR服务，当你申请获得百度这一项服务后，你可以在自己的服务器上通过client_id和client_secret使用百度提供OCR接口的功能，然后去开发一套自己的服务。

参考文章：

略