华企号 软件设计 OAuth 2.0的授权方式介绍以及规范实践和应用

OAuth 2.0的授权方式介绍以及规范实践和应用

基于实践说规范

网上看了一些OAuth 2.0的授权方法,尽管讲解的没有什么逻辑性错误,但是存在一个问题,那就是单纯的讲解协议规范却脱离了实际的应用,缺少干货,所以才有了这篇文章,内容基于实际业务进行讲解,力求基于实践说规范

OAuth 2.0

  OAuth 引入了一个授权层,用来分离两种不同的角色:客户端和资源所有者。……资源所有者同意以后,资源服务器可以向客户端颁发令牌。客户端通过令牌,去请求数据。

  OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种,向第三方应用颁发令牌。下面就是这四种授权方式。
授权码(authorization-code)
隐藏式(implicit)
密码式(password)
客户端凭证(client credentials)

分类解读

下面针对每一种进行详细的解读

  授权码(authorization code)

该类型的授权最为常见也是最安全的授权方式,指的是第三方应用先申请一个授权码,然后再用该码获取令牌,微信、支付宝等大的开放平台使用的基本都是这种方式。

案例讲解:A网站要实现微信用户的授权登录功能,首先A需要在微信公众平台注册一个应用,一般需要填写应用图标名称回调链接等信息(有些平台需要上传对应的非对称加密的公钥用于访问的非对称加密),审核通过后平台为该应用分配对应的参数一般包括:appId,appsecret等信息。

OAuth 2.0的授权方式介绍以及规范实践和应用插图

A网站开发人员拿到对应的信息后,需要携带appid、appsecret等信息访问开放平台指定链接,例如:

         https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECTURI&response_type=code&scope=SCOPE&state=STATE
 
              OAuth 2.0的授权方式介绍以及规范实践和应用插图1            OAuth 2.0的授权方式介绍以及规范实践和应用插图2
    通过上述链接进入到授权页面,如果未登录平台会要求用户微信登录,登录后平台会展示授权页面

当用户点击授权后,平台会回调A网站在注册应用时提供的回调地址(有些平台需要申请授权时实时的提供),并携带code码(如有必要需要同时携带其他参数比如state参数),A网站拿到code码后通过平台提供的sdk获取openid、token、expired、refresh_oken、refesh_time等信息(code为参数调用开放平台接口获取参数)

用户拿到openidtoken(令牌)就可以调用开放平台提供的服务了,到此,一个标准的授权码授权流程就结束了。需要知道的是token是有有效期的,适用方需要指定token刷新策略,通过refresh_oken调用刷新接口获取最新的token;

OAuth 2.0的授权方式介绍以及规范实践和应用插图3

思考:为什么开放平台回调的时候是返回code,而不是直接返回token、openid等信息

  • 直接返回token时涉及到跳转本身就是明文,可能被篡改的问题,需要协定复杂的签名协议来保证安全,这和 OAuth2 希望设计简洁验证模式的初衷违背;
  • 一般情况下code是用后即失效并且时效较短,无法重复使用和超时使用,但是token的有效期较长,并且能重复使用,某个用户对应的openid对A网站来说是唯一的,不会发生变化;
  • 要想获取token值需要提供appsecret作为参数(由第三方后端保存,不对外暴露),如果直接返回token,那么在页面授权的时候需要将appsecret显示的作为连接参数提供个开放平台,这显然不合理;

 

 

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

隐藏式授权的流程相对简单,但安全性不高,所以只能用于以下安全性要求不高的场景,其基本步骤如下:
  
第一步,A 网站提供一个链接,要求用户跳转到 B 网站,授权用户数据给 A 网站使用,如下:
https://b.com/oauth2/authorize?res_type=token&         
  client_id=CLIENT_ID&                        .
  redirect_uri=CALLBACK_URL&  
  scope=read

上面的url中res_type=token,标示返回的参数为token,也可以用其他的约定形式例如(authtype=implicit

第二步,用户跳转到 B 网站,登录后同意给予 A 网站授权。这时,B 网站就会跳回redirect_uri参数指定的跳转网址,并且把令牌作为 URL 参数,传给 A 网站。
https://a.com/callback#token=ACCESS_TOKEN

注意,令牌的位置是 URL 锚点(fragment),而不是查询参数,这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议,因此存在”中间人攻击”的风险,而浏览器跳转时,锚点不会发到服务器,就减少了泄漏令牌的风险。

关于token有效期的问题,一般采用隐藏式授权的的引用的有效期一般定为会话期间,随着浏览器关闭,令牌随之失效。一般不涉及到令牌的刷新问题(授权码授权需要定期的更新令牌)


密码式(password)

如果你高度信任某个应用,RFC 6749 也允许用户把用户名和密码,直接告诉该应用。该应用就使用你的密码,申请令牌,这种方式称为"密码式"(password)

OAuth 2.0的授权方式介绍以及规范实践和应用插图4

 

tips:B验证通过后不进行页面跳转而是把令牌放到json数据里面,最晚http回应的形式,返回对应的数据,个人认为这种形式要暴露自己的用户名和密码,风险性太大,因此只适用于其他授权方式无法采用的情况,不建议使用,现实实践中一般情况下使用appkey+secret+solt+timstamp+body数据加密的形式代替这种授权方法

 

客户端凭证(client credentials)


适用于没有前端的应用,即:第三方应用直接将appid、secret等参数作为凭证,通过后台接口调用授权方接口,授权方验证通过后直接返回对应的token信息
https://b.com/oauth/token?
  grant_type=refresh_token&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET&
  refresh_token=REFRESH_TOKEN

 

OAuth2.0仅仅是个协议或者说是个规范,本身没有什么意义,它的意义在于为尝试为某种授权场景提供思路和规范,在设计自己的授权协议或者对接某开放平台的时候,能够思路清理的理解每一个步骤,并且做出正确的选择,显示时间中授权码的形式经常遇到,另外三种暂未遇到过,一般都是带有加密算法的变形应用(接口鉴权),小伙伴们要灵活掌握;在后面的文章中我会详细讲解接口鉴权的集中形式。

上一篇
下一篇

发表回复

联系我们

联系我们

028-84868647

在线咨询: QQ交谈

邮箱: tech@68v8.com

工作时间:周一至周五,9:00-17:30,节假日休息

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

关注微博
返回顶部