这是我参与8月更文挑战的第21天,活动详情查看:8月更文挑战
OAuth2.0
的授权简单理解其实就是获取令牌(token
)的过程,OAuth
协议定义了四种获得令牌的授权方式(authorization grant
)如下:
- 授权码(
authorization-code
) - 隐藏式(
implicit
) - 密码式(
password
) - 客户端凭证(
client credentials
)
但值得注意的是,不管我们使用哪一种授权方式,在三方应用申请令牌之前,都必须在系统中去申请身份唯一标识:客户端 ID(client ID
)和 客户端密钥(client secret
)。这样做可以保证 token
不被恶意使用。
下面我们会分析每种授权方式的原理,在进入正题前,先了解 OAuth2.0
授权过程中几个重要的参数:
response_type
:code 表示要求返回授权码,token 表示直接返回令牌client_id
:客户端身份标识client_secret
:客户端密钥redirect_uri
:重定向地址scope
:表示授权的范围,read
只读权限,all
读写权限grant_type
:表示授权的方式,AUTHORIZATION_CODE
(授权码)、password
(密码)、client_credentials
(凭证式)、refresh_token
更新令牌state
:应用程序传递的一个随机数,用来防止CSRF
1 授权码模式
授权码模式(Authorization Code Grant)。
- 第一步:用户访问页面
- 第二步:访问的页面将请求重定向到认证服务器
- 第三步:认证服务器向用户展示授权页面,等待用户授权
- 第四步:用户授权,认证服务器生成一个code和带上client_id发送给应用服务器。然后,应用服务器拿到code,并用client_id去后台查询对应的client_secret
- 第五步:将code、client_id、client_secret传给认证服务器换取access_token和 refresh_token
- 第六步:将access_token和refresh_token传给应用服务器
- 第七步:验证token,访问真正的资源页面
掘金授权案例
OAuth2.0
四种授权中授权码方式是最为复杂,但也是安全系数最高的,比较常用的一种方式。这种方式适用于兼具前后端的Web
项目,因为有些项目只有后端或只有前端,并不适用授权码模式。下图我们以用WX
登录掘金为例,详细看一下授权码方式的整体流程。
用户选择WX
登录掘金,掘金会向WX
发起授权请求,接下来 WX
询问用户是否同意授权(常见的弹窗授权)。其中 response_type
为 code
要求返回授权码,scope
参数表示本次授权范围为只读权限,redirect_uri
重定向地址。
https://wx.com/oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=http://juejin.im/callback&
scope=read&
state=10001
用户同意授权后,WX
根据 redirect_uri
重定向并带上授权码。
http://juejin.im/callback?code=AUTHORIZATION_CODE
当掘金拿到授权码(code)时,带授权码和密匙等参数向WX
申请令牌。grant_type
表示本次授权为授权码方式 authorization_code
,获取令牌要带上客户端密匙 client_secret
,和上一步得到的授权码 code
。
https://wx.com/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=http://juejin.im/callback
最后 WX
收到请求后向 redirect_uri
地址发送 JSON
数据,其中的access_token
就是令牌。
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
......
}
2 简化模式
简化模式(Implicit Grant)。
- 第一步:用户访问页面时,重定向到认证服务器
- 第二步:认证服务器给用户一个认证页面,等待用户授权
- 第三步:用户授权,认证服务器想应用页面返回Token
- 第四步:验证Token,访问真正的资源页面
3 密码模式
密码模式(Resource Owner Password Credentials Grant)。
- 第一步:用户访问用页面时,输入第三方认证所需要的信息(QQ/微信账号密码)
- 第二步:应用页面那种这个信息去认证服务器授权
- 第三步:认证服务器授权通过,拿到token,访问真正的资源页面
优点:不需要多次请求转发,额外开销,同时可以获取更多的用户信息。
缺点:局限性,认证服务器和应用方必须有超高的信赖。
应用场景:自家公司搭建的认证服务器。
4 客户端模式
客户端模式(Client Credentials Grant)。
- 第一步:用户访问应用客户端
- 第二步:通过客户端定义的验证方法,拿到token,无需授权
- 第三步:访问资源服务器A
- 第四步:拿到一次token就可以畅通无阻的访问其他的资源页面。
这是一种最简单的模式,只要client请求,我们就将AccessToken发送给它。这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任,而client本身也是安全的。因此这种模式一般用来提供给我们完全信任的服务器端服务。在这个过程中不需要用户的参与。
4 隐藏式
上边提到有一些Web
应用是没有后端的, 属于纯前端应用,无法用上边的授权码模式。令牌的申请与存储都需要在前端完成,跳过了授权码这一步。前端应用直接获取 token
,response_type
设置为 token
,要求直接返回令牌,跳过授权码,WX
授权通过后重定向到指定 redirect_uri
。
https://wx.com/oauth/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=http://juejin.im/callback&
scope=read
5 密码式
密码模式比较好理解,用户在掘金直接输入自己的WX
用户名和密码,掘金拿着信息直接去WX
申请令牌,请求响应的 JSON
结果中返回 token
。grant_type
为 password
表示密码式授权。
https://wx.com/token?
grant_type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_ID
这种授权方式缺点是显而易见的,非常的危险,如果采取此方式授权,该应用一定是可以高度信任的。
7 凭证式
凭证式和密码式很相似,主要适用于那些没有前端的命令行应用,可以用最简单的方式获取令牌,在请求响应的 JSON
结果中返回 token
。grant_type
为 client_credentials
表示凭证式授权,client_id
和 client_secret
用来识别身份。
https://wx.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
8 常见问题
问题一:令牌怎么用?
拿到令牌可以调用 WX
API 请求数据了,那令牌该怎么用呢?每个到达WX
的请求都必须带上 token
,将 token
放在 http
请求头部的一个Authorization
字段里。如果使用postman
模拟请求,要在Authorization
-> Bearer Token
放入 token
,注意:低版本postman
没有这个选项。
问题二:令牌过期怎么办?
token
是有时效性的,一旦过期就需要重新获取,但是重走一遍授权流程,不仅麻烦而且用户体验也不好,那如何让更新令牌变得优雅一点呢?一般在颁发令牌时会一次发两个令牌,一个令牌用来请求API
,另一个负责更新令牌 refresh_token
。grant_type
为 refresh_token
请求为更新令牌,参数 refresh_token
是用于更新令牌的令牌。
https://wx.com/oauth/token?
grant_type=refresh_token&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
refresh_token=REFRESH_TOKEN