飞嗨,欢迎您的光临,本博所发布之文章皆为作者亲测通过,如有错误,欢迎通过各种方式指正。(本博已于2015.12.6升级到php7,运行环境php7 php-fpm + nginx1.8.0)

OAuth2之authorization code

Golang lf 1640℃ 0评论

OAuth2之authorization code

(移动)互联网发展到现在,一些基础类的产品(SNS、Email、IM…)已经相当完善。重复建设这些基础类的产品,未必能做到其更好。但是,基础类产品之间的自由组合,却能给到用户更好的体验效果(如,在新邮件到达的时候在QQ/wechat上直接提醒邮件到达、读取邮件)。同样,在我们自己的产品上中,整合这些基础产品之后,也能让我们的产品的使用成本大大降低(如,支持使用 google/facebook 账号登陆可以减少用户重复注册账号的麻烦,降低用户使用产品的壁垒、在 gmail 中收取到电商平台的发货通知邮件后,自动把物流信息追加AfterShip mobile tracking APP进行物流跟踪提醒,省去用户从邮件复制快递单号手动添加AfterShip mobile tracking APP的麻烦)。

要做到上面这些功能,最核心的问题是要解决鉴权问题。Gmail 如何确保 AfterShip 能有哪个用户的权限而允许读取哪个用户的邮件内容?当然,用户把 Gmail 账号密码告诉 AfterShip 是最简单。但是随之而来的问题:当用户修改密码?只想让 AfterShip 读取 Gamil 邮件但是不让发送邮件…?这些该如何控制?由此 OAuth2协议应运而生(这个协议的历史并不很遥远https://tools.ietf.org/html/draft-hammer-oauth2-00):独立了一层授权层。用户首先登Gmail授权层,然后选择授权哪部分权限给第三方,第三方再拿着用户的授权层给的令牌去资源服务器获取。果然,计算界中的任何问题,都可以通过加一个中间层来解决(ip地址不好记那就www.google.com;编码时0x0201=1麻烦就var int a=1…)

OAuth2 简介

为了解决各种场景,oauth2提供了好几种授权模式:

  • 授权码模式(authorization code) ,功能最完整,流程最严密模式

1

  • 简化模式,指对授权码模式的简化,比其少一个 code 换 token 步骤,其他完全一样

  • 密码模式,用户把密码给客户端,客户端以自己的名义所要授权,这种通常用户对客户端高度信任的情况,比如客户端是操作系统的一部分

  • 客户端模式,调用者是一个后端的模块,没有用户界面的时候,可以使用客户端模式。鉴权服务器直接对客户端进行身份验证,验证通过后,返回 token

  • 更新令牌,严格意义上他不算事一种授权模式,只是对上面模式的一种补充,当上面模式中获取到的token(令牌过期后),自动用 refresh_token 换一个新的 token

这些 OAuth2 模式,并没有优缺点之分,是为了针对不同的场景提供的决方案。在这些模式中,授权码模式,因为功能最完整,流程最严密,大多数场景也都满足,因此成了使用最多的模式:用户首先授权,授权完后跳回三方开发者的地址并带回了authorization code,三方开发者凭借authorization code再次向授权成请求返回 token。

起初,在web领域跑的很好,没有问题。但是随后而来的是移动互联网的兴起,大量的移动app使用授权码模式,产生了问题:当用户授权完后,把 authorization code 附在redirect_uri 跳转然后拉起 APP,是可能被其他应用窃取的(假设 redirect_uri 是aftership://com.aftership.tracking?code=authroization_code),那么这个aftership:// scheme是可能被其他恶意app抢注的,造成 authorization code 被其他 APP 窃取。因此又提出了适用移动app的授权码模式 authorization code with pkce。

2

在 authorization code with pkce 中,客户端拼装授权链接时,随机生成一个字符串,我们叫他 code_verifier,然后对此随机字符串进行非对称加密(加密算法必须保持和服务器一致)得到一个字符串,我们叫他 code_challenge,然后在把 code_challenge 拼到授权连接上。服务端下发 authorization_code 后,同时记住了这个 authorization code 对应的 code_chanllenge,然后客户端根据 authorzation code 和 code_verifier 再次换取 access token,服务端会检验根据同样的算法对 code_verifier 进行计算得到 secret 和 authorization code 对应的code_challenge对比,以确定是否是被冒用。假设在获取 authorization code 时被恶意 APP 获取,但是恶意 APP 是没有 code_verifier 这个值。pkce 主要解决移动端的场景,如果是移动端 APP 应该优先选用此模式,防止 authorization code 被截取。

在整个授权码模式中,我们看到,用 code 换取 token 时,万事已经尘埃落定了。所以对接过程中,这里一般不会有问题。相反,在拼接授权链接时,这些参数控制着整个授权行为。整个拼接授权链接是最重要的地方。而且 OAuth2 并没有统一的规范,不同厂家支持程度不一,需要仔细阅读厂商的文档。

Google OAuth2 授权链接参数

https://developers.google.com/identity/protocols/oauth2/web-server#creatingclient

client_id

必填

应用标识

redirect_uri

必填

用户授权完成跳转地址(在get参数上会带回authorization code)。这个地址必须在google后台配置白名单才能被使用

scope

必填

需要让用户授权的权限列表,多个权限用空格隔开(space-delimited)

access_type

建议填写

枚举值,online和offline,当为offline时才会返回refresh token,为online时不会返回refresh token

state

建议填写

透传字段,授权链接上指定的scope会在用户授权完成后跳转redirect_uri时带上此字段。用处很多,比如,防止cross-site攻击

include_granted_scopes

可选

枚举值,true或者false。当为true时,表示增量授权,即当用户授权后拿到的access token同时拥有本次授权的scopes和之前曾经授权过的scopes

login_hint

可选

如果你知道你想要哪个google账号授权(如,重新授权时,我们期待他授权该账号时)

prompt

可选

当用户已经授权过给应用后,默认以后不再展示授权页面给用户,登陆后直接跳转redirect_uri。此项可控制是否弹出授权页面。多个控制用空格隔开(space-delimeted)且大小写敏感。可控制的值:
none不显示同意授权页面,此值不可与其他值并用。

consent每次让用户进入选择同意授权。

select_account弹出让用户选择使用哪个账号。

Goole refresh token有效期限https://developers.google.com/identity/protocols/oauth2#expiration

  • 用户已经取消您的应用程序访问权限.

  • 6个月没有使用过 refresh token 刷新 access token.

  • 您要了 Gmail 的相关权限,用户修改密码

  • 用户超过了他能授权的最大 refrsh token 数量限制

目前每个用户只能授权给每个应用最多50个 refresh token,如果超出,新创建 refresh token 时候会自动作废最老的一个 refresh token 并且不会弹出警告。

 

注意事项

  • 按照 OAuth2 协议,使用 refresh token 刷新 access token 时,如果 refresh token 未过期,那么在返回 body 体消息是不会返回 refresh token 字段的,需要从get参数上(请求时用的) refresh token 取出.(见golang oauth2 sdk golang.org/x/oauth2/internal/token.go第226行 )

  • google oauth2中,在使用authorization code换取token时,仅在用户第一次授权时返回refresh token,以后不再返回(即使acceess_type=offline)。此时,我们可以在https://myaccount.google.com/permissions页面取消对应用的授权,那么再次授权就变成了第一次授权,会返回refresh token。另外,也可以在授权链接中prompt=consent每次让用户进入到授权确认页面,即可每次返回 refresh token

名词解释

  • authorization code,或者authorization_code,即授权码。有时简称code,指用户授权后,授权服务器临时生成的一个随机字符串,有效期通常在分钟级别内

  • token,即令牌。他是一组名词的总称。包括access_token,expires_in,refresh_token,而且token并不一定总是同时包括这些信息。

  • access_token,三方开发者请求资源服务器的凭证,通常有效期很短,仅几个小时之内。

  • expires_in,即(access_token)有效时间,单位通常是秒,如3600

  • refresh token,或者refresh_token,通常access_token的有效期非常短(几个小时之内),而refresh token的有效期基本上都是很久,比如google是6个月。三方开发者可以凭借此refresh token获取到新的token。

转载请注明:飞嗨 » OAuth2之authorization code

喜欢 (102)or分享 (0)

Warning: Use of undefined constant PRC - assumed 'PRC' (this will throw an Error in a future version of PHP) in /work/php/blog/wp-content/themes/yusi1.0/comments.php on line 17
发表我的评论
取消评论

表情
粤ICP备15018643号-1