写点什么

一口气说出 OAuth2.0 的四种授权方式

发布于: 2020 年 07 月 07 日
一口气说出 OAuth2.0 的四种授权方式

>本文收录在个人博客:www.chengxy-nds.top,技术资源共享,一起进步



上周我的自研开源项目开始破土动工了,[《开源项目迈出第一步,10 选 1?页面模板成了第一个绊脚石

》](https://mp.weixin.qq.com/s/vFHpxh3sry1p-Yj0Q7ZwJQ) ,密谋很久才付诸行动,做这个的初衷就是不想让自己太安稳,技术这条路不进步就等于后退,必须要逼着自己学习。



项目偏向于技术实践,因此不会做太多的业务堆砌,业务代码还是在公司学习比较好。现在正在做技术的选型与储备,像比较主流的,项目前后端分离微服务SpringbootSpringcloud 等都会应用到项目中,其实很多技术我也不会,也是在反复的查阅资料求证,探索的过程技术提升真的要比工作中快很多,毕竟主动与被动学习是有本质区别的。



这几天打算先把项目的前后端分离架构搭建完成,既然是前后端分离项目就免不了做鉴权, 所以 oauth2.0 是一个我们不得不了解的知识点。






一、OAuth2.0 为何物

OAuth 简单理解就是一种授权机制,它是在客户端和资源所有者之间的授权层,用来分离两种不同的角色。在资源所有者同意并向客户端颁发令牌后,客户端携带令牌可以访问资源所有者的资源。



OAuth2.0OAuth 协议的一个版本,有2.0版本那就有1.0版本,有意思的是OAuth2.0 却不向下兼容OAuth1.0 ,相当于废弃了1.0版本。



举个小栗子解释一下什么是 OAuth 授权?



在家肝文章饿了定了一个外卖,外卖小哥30秒火速到达了我家楼下,奈何有门禁进不来,可以输入密码进入,但出于安全的考虑我并不想告诉他密码。



此时外卖小哥看到门禁有一个高级按钮“一键获取授权”,只要我这边同意,他会获取到一个有效期 2小时的令牌(token)正常出入。





令牌(token)和 密码 的作用虽然相似都可以进入系统,但还有点不同。token 拥有权限范围,有时效性的,到期自动失效,而且无效修改。



二、OAuth2.0 授权方式

OAuth2.0 的授权简单理解其实就是获取令牌(token)的过程,OAuth 协议定义了四种获得令牌的授权方式(authorization grant )如下:



  • 授权码(authorization-code

  • 隐藏式(implicit

  • 密码式(password):

  • 客户端凭证(client credentials



但值得注意的是,不管我们使用哪一种授权方式,在三方应用申请令牌之前,都必须在系统中去申请身份唯一标识:客户端 ID(client ID)和 客户端密钥(client secret)。这样做可以保证 token 不被恶意使用。



下面我们会分析每种授权方式的原理,在进入正题前,先了解 OAuth2.0 授权过程中几个重要的参数:



  • response_type:code 表示要求返回授权码,token 表示直接返回令牌

  • client_id:客户端身份标识

  • client_secret:客户端密钥

  • redirect_uri:重定向地址

  • scope:表示授权的范围,read只读权限,all读写权限

  • grant_type:表示授权的方式,AUTHORIZATION_CODE(授权码)、password(密码)、client_credentials(凭证式)、refresh_token 更新令牌

  • state:应用程序传递的一个随机数,用来防止CSRF攻击。



1、授权码

OAuth2.0四种授权中授权码方式是最为复杂,但也是安全系数最高的,比较常用的一种方式。这种方式适用于兼具前后端的Web项目,因为有些项目只有后端或只有前端,并不适用授权码模式。



下图我们以用WX登录掘金为例,详细看一下授权码方式的整体流程。





用户选择WX登录掘金,掘金会向WX发起授权请求,接下来 WX 询问用户是否同意授权(常见的弹窗授权)。response_typecode 要求返回授权码,scope 参数表示本次授权范围为只读权限,redirect_uri 重定向地址。



https://wx.com/oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=http://juejin.im/callback&
scope=read



用户同意授权后,WX 根据 redirect_uri重定向并带上授权码。



http://juejin.im/callback?code=AUTHORIZATION_CODE

当掘金拿到授权码(code)时,带授权码和密匙等参数向WX申请令牌。grant_type表示本次授权为授权码方式 authorization_code ,获取令牌要带上客户端密匙 client_secret,和上一步得到的授权码 code



https://wx.com/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=http://juejin.im/callback

最后 WX 收到请求后向 redirect_uri 地址发送 JSON 数据,其中的access_token 就是令牌。



{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
......
}



2、隐藏式



上边提到有一些Web应用是没有后端的, 属于纯前端应用,无法用上边的授权码模式。令牌的申请与存储都需要在前端完成,跳过了授权码这一步。



前端应用直接获取 tokenresponse_type 设置为 token,要求直接返回令牌,跳过授权码,WX授权通过后重定向到指定 redirect_uri



https://wx.com/oauth/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=http://juejin.im/callback&
scope=read



3、密码式

密码模式比较好理解,用户在掘金直接输入自己的WX用户名和密码,掘金拿着信息直接去WX申请令牌,请求响应的 JSON结果中返回 tokengrant_typepassword 表示密码式授权。



https://wx.com/token?
grant_type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_ID

这种授权方式缺点是显而易见的,非常的危险,如果采取此方式授权,该应用一定是可以高度信任的。



4、凭证式

凭证式和密码式很相似,主要适用于那些没有前端的命令行应用,可以用最简单的方式获取令牌,在请求响应的 JSON 结果中返回 token



grant_typeclient_credentials 表示凭证式授权,client_idclient_secret 用来识别身份。



https://wx.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET



三、令牌的使用与更新



1、令牌怎么用?

拿到令牌可以调用 WX API 请求数据了,那令牌该怎么用呢?



每个到达WX的请求都必须带上 token,将 token 放在 http 请求头部的一个Authorization字段里。



如果使用postman 模拟请求,要在Authorization -> Bearer Token 放入 token注意:低版本postman 没有这个选项。





2、令牌过期怎么办?

token是有时效性的,一旦过期就需要重新获取,但是重走一遍授权流程,不仅麻烦而且用户体验也不好,那如何让更新令牌变得优雅一点呢?



一般在颁发令牌时会一次发两个令牌,一个令牌用来请求API,另一个负责更新令牌 refresh_tokengrant_typerefresh_token 请求为更新令牌,参数 refresh_token 是用于更新令牌的令牌。



https://wx.com/oauth/token?
grant_type=refresh_token&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
refresh_token=REFRESH_TOKEN



总结

OAuth2.0 授权其实并不是很难,只不过授权流程稍显麻烦,逻辑有些绕,OAuth2.0它是面试经常会被问到的知识点,还是应该多了解一下。下一篇实战 OAuth2.0四种授权,敬请期待,欢迎关注哦~



原创不易,燃烧秀发输出内容,如果有一丢丢收获,点个赞鼓励一下吧!



整理了几百本各类技术电子书,送给小伙伴们。关注公号回复【666】自行领取。和一些小伙伴们建了一个技术交流群,一起探讨技术、分享技术资料,旨在共同学习进步,如果感兴趣就加入我们吧!





发布于: 2020 年 07 月 07 日阅读数: 2424
用户头像

不积跬步,无以至千里 2018.07.03 加入

公众号-程序员内点事,一个技术传播者

评论 (2 条评论)

发布
用户头像
授权码模式的例子中,为什么最后还要带上client_secret去为用户获取token,这不是把client_secret暴露到前端了吗?我不清楚这是例子错了还是腾讯OAuth服务的特殊之处,但是根据我的经验这应该是错误的。至少Azure AD的流程不是这样的。
2020 年 07 月 21 日 16:10
回复
授权的过程,都是后端的在做。最终,拿到WX token后,前端再用token去访问WX的信息
2020 年 07 月 28 日 17:00
回复
没有更多了
一口气说出 OAuth2.0 的四种授权方式