FOEVERYANG资料

本文主要介绍FOEVERYANG资料 方法和在新技术下所面对的“挑战”,方便大家深入理解FOEVERYANG资料 过程。本文也将分享FOEVERYANG资料 所遇到的问题和应对策略,怎么解决怎么做的问题。
通过深入本文可以理解代码原理,进行代码文档的下载,也可以查看相应 Demo 部署效果。

基于实践说规范

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

OAuth 2.0

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

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

分类解读

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

  授权码(authorization code)

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

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

    FOEVERYANG

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

         https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECTURI&response_type=code&scope=SCOPE&state=STATE
    
 
              FOEVERYANG            FOEVERYANG
    通过上述链接进入到授权页面,如果未登录平台会要求用户微信登录,登录后平台会展示授权页面

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

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

       FOEVERYANG

     思考:为什么开放平台回调的时候是返回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)

              FOEVERYANG

 

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

参考链接:http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html

FOEVERYANG资料部分资料来自网络,侵权毕设源码联系删除

区块链毕设网(www.qklbishe.com)全网最靠谱的原创区块链毕设代做网站
部分资料来自网络,侵权联系删除!
资源收费仅为搬运整理打赏费用,用户自愿支付 !
qklbishe.com区块链毕设代做网专注|以太坊fabric-计算机|java|毕业设计|代做平台 » FOEVERYANG资料

提供最优质的资源集合

立即查看 了解详情