Oauth2系列6：隐式模式

传送门

Oauth2系列1：初识Oauth2

Oauth2系列2：授权码模式

Oauth2系列3：接入前准备

Oauth2系列4：密码模式

Oauth2系列5：客户端凭据模式

在前面几节，介绍了Oauth2的授权码，密码，客户端凭据模式。这里讨论下最后一种隐式模式，也是最不安全的一种

程序员真的晚景凄凉？

请允许稍微标题党一次。一点感慨，最近大环境不好，裁员之声不绝于耳，再加上疫情影响，以现在这种高压态势，短时间也很恢复。

哀民生之多艰！

程序员的出路在哪？当然不是买课，也不是外卖。

夯实基础吧，操作系统/网络/数据结构与算法/计算机组成原理，静待花开，静待转机的到来！

什么是隐式模式

定义

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。

应用场景

从定义里面可知，对于没有后端服务的应用，可以采用隐藏式，直接颁发token。这里主要的原因是，如果没有后端服务，一般意味着也没有对应的系统存储服务，或者不安全，所以不能存储证明应用身份的clientSecret

clientSecret

客户端密钥（client secret）

整个获取token的示意流程如下

隐藏模式的目的，最终还是获取授权的令牌：由于没有后端服务，所以也不存在敏感信息保护，并且此时的获取令牌也只能通过前端信道交互。

隐式模式流程 

隐式模式的流程其实跟密码模式，客户端凭据模式相似，整个流程都是归纳为一种步骤：第三方系统通过凭据获取令牌，只是这里凭据只有一个client_id而已。那么对于系统接口设计来说，是不是一个API接口就可以满足呢？

其实是可以的，比如可以如下定义接口：

URL：http://oauth.x.com/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&state=UUID

请求方式：GET

请求参数：

字段	说明
response_type	固定token，表示要求直接返回令牌。
client_id	客户端 ID（client ID）
redirect_uri	redirect_uri参数指定的跳转网址，必须跟尝试用注册时的保持一致
state	用于保持请求和回调的状态，授权请求后原样带回给第三方。该参数可用于防止 csrf 攻击（跨站请求伪造攻击），建议第三方带上该参数

返回参数：

{ 
"access_token":"ACCESS_TOKEN", 
"expires_in":720, 
"refresh_token":"REFRESH_TOKEN",
"scope":"SCOPE"
}

• 但是这里有需要特别注意的地方，一般情况下，是不建议使用此模式的，因为非常不安全，如果有特殊需求，可以使用变体的PKCE 的授权码模式
• 隐藏模式获取token是通过的前端信道，也即是GET请求，并且服务端采用重定向的方式回传token信息，所以请求里面一定要带上redirect_uri
• 服务端的回传一般是http://a.com/callback#token=ACCESS_TOKEN这种形式，所以令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险
• 同第一点，这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。
• 刷新令牌也是不需要的