
1.2 OAuth 2的四种授权模式
1.2.1 隐式授权模式
1.授权请求示例
步骤1 隐式授权(Implicit Grant)模式引导用户在登录页面登录,在用户登录成功后,通过授权系统将用户的授权信息回调到第三方应用,在第三方应用拿到授权信息后,便可调用开放能力。隐式授权请求如示例1.1所示。

示例1.1 隐式授权请求
注意
在这里统一说明一下,示例中使用“##”代表一个参数值,后文均遵循该规则。
示例1.1中各参数的含义如下。
• client_id:第三方应用在开放平台注册完成后获取的唯一标识。
• redirect_url:第三方应用在开放平台注册的回调地址。
• scope:第三方应用的访问权限,一般由逗号分隔的多个字符串组成。
• response_type:默认值为token,即返回授权的token。
步骤2 假设第三方应用设置的回调地址为https://example.com/callback,在第三方应用引导用户发起步骤1后,会跳转到用户登录页面。在用户登录成功后,授权系统会生成token,并通过第三方应用预设的回调地址回调到第三方应用。隐式授权回调请求如示例1.2所示。

示例1.2 隐式授权回调请求
示例1.2中各参数的含义如下。
• https://example.com/callback:第三方应用预设的回调地址,授权系统在授权成功后,会直接回调到该地址。
• access_token:访问令牌,用户授权的唯一凭证,可代表用户调用授权的开放接口。
• token_type:token的类型,一般为bearer。该类型的token是一串字符串,通常为一串十六进制形式的字符串或JWT(一种结构化的token表示方法)。还有一些其他类型,如POP。随着HTTPS协议的普及和签名的使用,基本不再使用该类型的token。
• expires_in:token的过期时间,单位为秒。
2.系统交互流程
下面通过如图1-1所示的隐式授权系统交互图来进一步讲解授权流程。
步骤1 用户访问第三方应用。
步骤2 第三方应用引导用户向授权系统发起授权请求,详见示例1.1。

图1-1 隐式授权系统交互图
步骤3 授权系统进行初步校验,校验参数是否合法,如client_id是否存在,redirect_url是否一致等。在校验通过后,重定向到认证系统,并发起用户认证。
步骤4 用户在认证系统中成功登录后,会从认证系统回调到授权系统。授权系统可以获取用户信息,在进行必要的授权流程后,生成access_token。
步骤5 授权系统重定向到第三方应用设置的回调地址,详见示例1.2。
经验
隐式授权模式安全性不高,在实际中应用不多,原因如下。
(1)在授权系统回调到第三方应用(图1-1的步骤5)时,token会直接作为参数在浏览器中显示,有暴露token的风险。
(2)如果第三方应用所设置的回调地址不是示例1.2中的https请求,而是普通的http请求,则会因为http的非加密传输,而带来参数被拦截的风险。
(3)可能无法刷新token的有效期,过期后只能重新授权。