OAuth2.0 4种授权方式

雨点打透心脏的1/2处 2024-03-31 10:18 67阅读 0赞

参考博客：https://blog.csdn.net/lsy0903/article/details/113769131

## OAuth 2.0 ##

OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。资源所有者同意以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据。  
OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。下面就是这四种授权方式。

**授权码（authorization-code）  
隐藏式（implicit）  
密码式（password）  
客户端凭证（client credentials）**

#### 授权码（authorization code） ####

案例讲解：A网站要实现微信用户的授权登录功能，首先A需要在微信公众平台注册一个应用，一般需要填写应用图标、名称、回调链接等信息（有些平台需要上传对应的非对称加密的公钥用于访问的非对称加密），审核通过后平台为该应用分配对应的参数一般包括：appId，appsecret等信息。  
　![在这里插入图片描述][35840ed695174a2d8edd7bdccc43b486.png]A网站开发人员拿到对应的信息后，需要携带appid、appsecret等信息访问开放平台指定链接，例如：https://open.weixin.qq.com/connect/oauth2/authorize?appid=***APPID***&redirect\_uri=***REDIRECTURI***&response\_type=***code***&scope=***SCOPE***&state=***STATE***  
![在这里插入图片描述][ee44dae3328a4400a113999aeee9b98c.png]  
![在这里插入图片描述][3ce6d10dc4044a18ac57e79ca2eefd04.png]  
通过上述链接进入到授权页面，如果未登录平台会要求用户微信登录，登录后平台会展示授权页面

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

用户拿到openid和token（令牌）就可以调用开放平台提供的服务了,到此，一个标准的授权码授权流程就结束了。需要知道的是token是有有效期的，适用方需要指定token刷新策略,通过refresh\_oken调用刷新接口获取最新的token；  
![在这里插入图片描述][91ca34b3e2c3495ba1c37fe27a1d5107.png]  
思考：为什么开放平台回调的时候是返回code，而不是直接返回token、openid等信息  
1、直接返回token时涉及到跳转本身就是明文，可能被篡改的问题，需要协定复杂的签名协议来保证安全，这和 OAuth2 希望设计简洁验证模式的初衷违背；  
2、一般情况下code是用后即失效并且时效较短，无法重复使用和超时使用，但是token的有效期较长，并且能重复使用，某个用户对应的openid对A网站来说是唯一的，不会发生变化；  
3、要想获取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）

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

[35840ed695174a2d8edd7bdccc43b486.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/f0fd954bbe8242528434ab5a932688e6.png
[ee44dae3328a4400a113999aeee9b98c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/d7f67c1711404bc2a4ea624cf48ebf21.png
[3ce6d10dc4044a18ac57e79ca2eefd04.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/f830dfbe6b494764ab6ca95d7dff6918.png
[91ca34b3e2c3495ba1c37fe27a1d5107.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/4119153f530a4051af1b1a8e60ec4aae.png
[118d8c2fd5d8423c8fe18441ddab3feb.jpeg_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/0a161feeaa5c480990a86ffc90c21d8d.jpeg