应用场景:有后端的 Web 应用。
好处:这种方式是最常用的流程,安全性也最高,授权码通过前端传送,令牌则是储存在后端,而且所有与资源服务器的通信都在后端完成。这样的前后端分离,可以避免令牌泄漏。
下面就是 A 网站跳转 B 网站的一个示意链接。
https://b.com/oauth/authorize?
response_type=code& //表示要求返回授权码
client_id=CLIENT_ID& //让 B 知道是谁在请求
redirect_uri=CALLBACK_URL& // B 接受或拒绝请求后的跳转网址
scope=read//表示要求的授权范围(这里是只读)。
https://a.com/callback?code=AUTHORIZATION_CODE
上面 URL 中,code参数就是授权码。
https://b.com/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=CALLBACK_URL
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{...}
}
上面 JSON 数据中,access_token字段就是令牌,A 网站在后端拿到了。
应用场景: Web 应用是纯前端应用,没有后端。
好处:允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤,所以称为(授权码)“隐藏式”(implicit)。
https://b.com/oauth/authorize?
response_type=token& //表示要求直接返回令牌
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read
https://a.com/callback#token=ACCESS_TOKEN
注意,令牌的位置是URL锚点(fragment),而不是查询字符串(querystring),这是因为 OAuth 2.0 允许跳转网址是HTTP协议,因此存在"中间人攻击"的风险,而浏览器跳转时,锚点不会发到服务器,就减少了泄漏令牌的风险。
应用场景:你高度信任某个应用
好处:只适用于其他授权方式都无法采用的情况
- 第一步:A网站要求小明输入账号密码。拿到以后,A网站向B网站请求令牌
https://oauth.b.com/token?
grant_type=password& //表示"密码式"
username=USERNAME&
password=PASSWORD& //B 的用户名和密码。
client_id=CLIENT_ID
应用场景:适用于没有前端的命令行应用
好处:这种方式给出的令牌,是针对第三方应用的,而不是针对用户的,即有可能多个用户共享同一个令牌。
https://oauth.b.com/token?
grant_type=client_credentials&//表示采用凭证式
client_id=CLIENT_ID&//用来让 B 确认 A 的身份。
client_secret=CLIENT_SECRET