OAuth 2.0 实战课
王新栋
京东资深架构师
16397 人已学习
新⼈⾸单¥29
登录后,你可以任选2讲全文学习
课程目录
已完结/共 17 讲
开篇词 (1讲)
OAuth 2.0 实战课
15
15
1.0x
00:00/00:00
登录|注册

06 | 除了授权码许可类型,OAuth 2.0还支持什么授权流程?

你好,我是王新栋。
在前面几讲学习授权码许可类型的原理与工作流程时,不知道你是不是一直有这样一个疑问:授权码许可的流程最完备、最安全没错儿,但它适合所有的授权场景吗?在有些场景下使用授权码许可授权,是不是过于复杂了,是不是根本就没必要这样?
比如,小兔打单软件是京东官方开发的一款软件,那么小明在使用小兔的时候,还需要小兔再走一遍授权码许可类型的流程吗?估计你也猜到答案了,肯定是不需要了。
你还记得授权码许可流程的特点么?它通过授权码这种临时的中间值,让小明这样的用户参与进来,从而让小兔软件和京东之间建立联系,进而让小兔代表小明去访问他在京东店铺的订单数据。
现在小兔被“招安”了,是京东自家的了,是被京东充分信任的,没有“第三方软件”的概念了。同时,小明也是京东店铺的商家,也就是说软件和用户都是京东的资产。这时,显然没有必要再使用授权码许可类型进行授权了。但是呢,小兔依然要通过互联网访问订单数据的 Web API,来提供为小明打单的功能。
于是,为了保护这些场景下的 Web API,又为了让 OAuth 2.0 更好地适应现实世界的更多场景,来解决比如上述小兔软件这样的案例,OAuth 2.0 体系中还提供了资源拥有者凭据许可类型。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

OAuth 2.0是一种授权框架,支持多种授权许可类型,包括授权码许可、资源拥有者凭据许可、客户端凭据许可和隐式许可类型。隐式许可适用于浏览器端执行的纯JavaScript应用,无需后端服务的情况。在这种情况下,授权流程可以使用隐式许可流程,直接返回access_token的值。然而,隐式许可流程的安全性较低,因为整个流程在前端通信中完成,没有服务端参与。因此,在选择授权许可类型时,应根据实际情况进行考虑。建议优先考虑授权码许可类型,然后根据实际生产环境选择合适的授权许可类型。总的来说,授权码许可类型具有最高的安全性,而其他类型则根据特定场景选择使用。文章还提供了相关示例代码和思考题,帮助读者更好地理解和应用OAuth 2.0的授权许可类型。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《OAuth 2.0 实战课》
新⼈⾸单¥29
立即购买
登录 后留言

全部留言(36)

  • 最新
  • 精选
  • Geek_4b64df
    可以,微信小程序就用的授权码,通过ajax获取code

    作者回复: 是的

    2020-07-13
    3
    14
  • kylexy_0817
    感觉用户名密码获取到的access_token,和sessionid很像,只是session id只要用户有操作,就会自动续约,但access_token,会定期更新?

    作者回复: sessionid和access_token是两个完全不同的事物,sessionid是会话,access_token不能等同于会话,它是第三方软件代表用户访问数据的凭证。

    2020-07-14
    2
    9
  • stg609
    写的很不错! 有几个疑问: 1. 使用隐式许可类型的时候,在请求授权服务器的时候,redirect uri 并不是必须的,而且也没有app secret, 那授权服务器是如何验证client的合法性的? 随便给一个 app id 如何? 2. 除了隐式许可不需要app secret,其他几种是否都是强制的 3. 授权码及隐式许可类型在注册 client 的 时候,redirect uri 是否都是必须的?但是在第一次访问授权服务器的时候redirect uri 都不是必须提供? 4. 对于SPA, 隐式许可现在已经不再推荐了,更推荐 使用PKCE 的授权码模式,课程是否有介绍?

    作者回复: 1、也是按照第三方应用提前在平台上申请好的appid来判断验证。 2、是的。 3、必须的。 4、PKCE后面课程有介绍,这是一个增补协议,并不是授权许可类型之一。

    2020-08-15
    4
  • 龙堂修罗
    隐式授权使用appid请求acesstoken是不是有点多余,因为appid肯定会被抓到的。这种方式是不是就没用了

    作者回复: 隐式许可类型的初衷是为了让嵌入到浏览器内应用也能够使用上OAuth2.0的方案,那么在”基础设施“都欠缺的情况下,比如就是没有或者不用服务端这样的时候,也能有一个选择。一般这样的应用使用时长都会很短暂,用完即走。

    2020-08-06
    2
    4
  • suhuijie
    资源拥有者凭据许可,直接用用户名密码是前端登陆还是后端登陆?例子中还需要携带appID和秘钥,那就是需要后端登陆。那这样的情况就是,官方出品所的产品都要自己提供登录接口,然后后端服务绕一圈去登录?能否直接在前端直接用用户名和密码登录?

    作者回复: 登录和授权是两个通路的事情,任何授权都是在用户登录之后进行的。 用户的用户名和密码是来进行登陆的,appID和秘钥是用来换取访问令牌的。 授权的本质是令牌,令牌是怎么换来的呢,是用户登录之后的授权,那生成令牌的时候是怎么跟用户的登录关联上的呢,因为授权和登录的后台处理都是”一家“的。 并不是说后端服务绕一圈再去登录,而且生产中登录和授权本来也是有分别的系统来进行处理。

    2020-07-16
    2
    4
  • 蒋胜琳
    搜索了好多博客,都没有把各种许可讲明白的,在这里可算明白了

    作者回复: 感谢支持

    2020-07-13
    4
  • leros
    理论上讲,没有浏览器的情况下,也可以实现授权码许可流程。这种流程需要一个user agent让用户和第三方软件互动,并接受来自授权服务器的重定向,而浏览器只是最常见的user agent,不过不太清楚具体实践中这一块怎么处理的。

    作者回复: 在07我们讲到了不需要浏览器参与使用授权码的场景。

    2020-07-11
    4
  • CC
    有一个疑问想请教老师:用户登录是否应该采用 OAuth 的形式? 假如一个 React Web App 应用,自己有后端,用户注册、登录以及获取受保护资源都是采用 OAuth 的方式。比如,用户登录成功后,后端直接给前端返回 access token,前端把 access token 保存在内存中(比如 Redux Store)里面。 这种案例还属于「授权」吗?如果是,又是属于什么类型呢? 看到老师在评论里面回复,“登录和授权是两个通路的事情,任何授权都是在用户登录之后进行的。” 根据这点,我认为例子中的登录即使采用 OAuth,也可能不属于 OAuth 的讨论范围,但不是很确定。

    作者回复: 你说的可以称为借助了OAuth的理念,并不是严格意义上的授权。另外用户登录跟授权是两个不同的事情。

    2020-08-11
    3
  • Geek_9d0e04
    使用 资源拥有在凭据许可和隐式许可 方式时,没有了最终用户选择授权的过程,都是直接获取access_token,那授权服务做权限校验时,如何控制呢??

    作者回复: 无论哪种许可方式都会生成access_token,在生成access_token的时候,对应的权限也都在用户授权的那一刻分配好了,要么是用户显式的在页面上选择了授权的权限内容,要么是后台默认采用了事先平台分配给应用的权限内容。

    2020-08-08
    2
  • Geek_7b4330
    老师,如果小兔是京东的官方APP,然后小兔本身除了账号密码登录,还集成了微信登录,登录流程又会是怎样呢?

    作者回复: 如果使用了微信登录就走了OAuth2.0流程,自身的登录没有。

    2020-08-10
    2
    1
收起评论
显示
设置
留言
36
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部