OAuth 2.0实战课
王新栋
京东资深架构师
立即订阅
2527 人已学习
课程目录
已完结 17 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 为什么要学OAuth 2.0?
免费
基础篇 (6讲)
01 | OAuth 2.0是要通过什么方式解决什么问题?
02 | 授权码许可类型中,为什么一定要有授权码?
03 | 授权服务:授权码和访问令牌的颁发流程是怎样的?
04 | 在OAuth 2.0中,如何使用JWT结构化令牌?
05 | 如何安全、快速地接入OAuth 2.0?
06 | 除了授权码许可类型,OAuth 2.0还支持什么授权流程?
进阶篇 (8讲)
07 | 如何在移动App中使用OAuth 2.0?
08 | 实践OAuth 2.0时,使用不当可能会导致哪些安全漏洞?
09 | 实战:利用OAuth 2.0实现一个OpenID Connect用户身份认证协议
10 | 串讲:OAuth 2.0的工作流程与安全问题
11 | 实战案例:使用Spring Security搭建一套基于JWT的OAuth 2.0架构
12 | 架构案例:基于OAuth 2.0/JWT的微服务参考架构
13 | 各大开放平台是如何使用OAuth 2.0的?
14 | 查漏补缺:OAuth 2.0 常见问题答疑
结束语 (2讲)
期末测试 | 一套习题,测试你的掌握程度
结束语 | 把学习当成一种习惯
OAuth 2.0实战课
15
15
1.0x
00:00/00:00
登录|注册

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

王新栋 2020-07-11
你好,我是王新栋。
在前面几讲学习授权码许可类型的原理与工作流程时,不知道你是不是一直有这样一个疑问:授权码许可的流程最完备、最安全没错儿,但它适合所有的授权场景吗?在有些场景下使用授权码许可授权,是不是过于复杂了,是不是根本就没必要这样?
比如,小兔打单软件是京东官方开发的一款软件,那么小明在使用小兔的时候,还需要小兔再走一遍授权码许可类型的流程吗?估计你也猜到答案了,肯定是不需要了。
你还记得授权码许可流程的特点么?它通过授权码这种临时的中间值,让小明这样的用户参与进来,从而让小兔软件和京东之间建立联系,进而让小兔代表小明去访问他在京东店铺的订单数据。
现在小兔被“招安”了,是京东自家的了,是被京东充分信任的,没有“第三方软件”的概念了。同时,小明也是京东店铺的商家,也就是说软件和用户都是京东的资产。这时,显然没有必要再使用授权码许可类型进行授权了。但是呢,小兔依然要通过互联网访问订单数据的 Web API,来提供为小明打单的功能。
于是,为了保护这些场景下的 Web API,又为了让 OAuth 2.0 更好地适应现实世界的更多场景,来解决比如上述小兔软件这样的案例,OAuth 2.0 体系中还提供了资源拥有者凭据许可类型。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《OAuth 2.0实战课》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥9.9
立即订阅
登录 后留言

精选留言(23)

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

    作者回复: 是的

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

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

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

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

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

    作者回复: 感谢支持

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

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

    2020-07-11
    1
  • 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
  • CC
    有一个疑问想请教老师:用户登录是否应该采用 OAuth 的形式?

    假如一个 React Web App 应用,自己有后端,用户注册、登录以及获取受保护资源都是采用 OAuth 的方式。比如,用户登录成功后,后端直接给前端返回 access token,前端把 access token 保存在内存中(比如 Redux Store)里面。

    这种案例还属于「授权」吗?如果是,又是属于什么类型呢?

    看到老师在评论里面回复,“登录和授权是两个通路的事情,任何授权都是在用户登录之后进行的。” 根据这点,我认为例子中的登录即使采用 OAuth,也可能不属于 OAuth 的讨论范围,但不是很确定。

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

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

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

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

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

    2020-08-08
  • tongmin_tsai
    老师,如果类似于传统使用session那样,如果我每次使用access_token请求后,希望重置过期时间,怎么做才是最佳实践?

    作者回复: 我尝试理解你是说重置【access_token】的过期时间么,这个过期时间不能被重置,但可以使用刷新令牌来更换一个新的access_token。

    2020-07-28
  • 慎独明强
    OAuth 2.0授权码许可类型,这个是最安全的,需要用户登录与授权,返回授权码给第三方软件,第三方软件再去换取token和刷新token。 资源拥有者访问类型:用户 第三方软件与授权服务都是官方的,那么用户通过输入用户名和密码,去授权服务拿到token。
    2020-07-23
  • 在路上
    王老师,公司内部的统一登录,一般选用OAuth那种验证类型呢?

    作者回复: 由于是公司内部系统,可以使用OAuth2.0的简化模式,也就是隐式许可类型,但是像通过微信、微博这样的方式就要使用授权码许可类型。

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

    作者回复:
    登录和授权是两个通路的事情,任何授权都是在用户登录之后进行的。

    用户的用户名和密码是来进行登陆的,appID和秘钥是用来换取访问令牌的。

    授权的本质是令牌,令牌是怎么换来的呢,是用户登录之后的授权,那生成令牌的时候是怎么跟用户的登录关联上的呢,因为授权和登录的后台处理都是”一家“的。

    并不是说后端服务绕一圈再去登录,而且生产中登录和授权本来也是有分别的系统来进行处理。

    2020-07-16
  • 在这里系统的学习了一下oauth2.0,讲的很清楚,收获很多

    作者回复: 感谢支持

    2020-07-15
  • Ryan Pan
    资源拥有者凭据许可是用用户帐户密码取得token,那有没有从第三方帐户(微信等)取得token的方式呢?
    例如用从第三方取得的access_token换授权服务的token之类的
    2020-07-14
  • Geek_9ae2b9
    对比了授权码许可类型,本文介绍的三种授权流程中,都不需要经过用户小明的“授权”操作吗?

    作者回复: 只有客户端凭据许可不需要

    2020-07-13
  • Geek_4b64df
    您是 隐式许可 讲的最透彻的一位老师

    作者回复: 感谢支持

    2020-07-13
  • DB聪
    请问”如果小兔软件是官方出品,那么可以直接使用客户端凭据许可;”是否应该是”如果小兔软件是官方出品,那么可以直接使用资源拥有者凭据许可;”?

    作者回复: 感谢指正,这里是一个错误。

    在如何选择,这一段,应该更正为:【如果小兔软件是官方出品,那么可以直接使用资源拥有者凭据许可;】

    其实,我们在刚开始的时候一直在讲官方出品-资源拥有者凭据许可。再次感谢,已做修改。

    2020-07-12
    1
  • Geek_9d0e04
    总结部分:如果小兔软件是官方出品,那么可以直接使用客户端凭据许可;这个写错了吧,应该是使用资源拥有者凭证许可。还有一个问题,隐式许可时,没有refresh_token,那accesss_token过期了,每次过期都需要资源拥有者参与,再走一遍认证过程嘛??这不是没法在生产中使用吗

    作者回复: 感谢指正,这里是一个错误。已联系更正修改。

    针对隐式许可类型的场景的特点是,浏览器内的应用都是短暂运行,只会在被加载到浏览器的这期间保持会话,所以刷新令牌在这里的作用很有限。

    2020-07-12
  • hhhh
    对于授权服务而言,支持隐式类型还要对注册的域名增加跨域支持吧?

    作者回复: 隐式许可类型实际应用在生产环境中的机会非常小了,比如直接嵌入浏览器这样的应用,在我们的实际生产环境中很少。因此,大家的重点不要放在这个授权许可类型上。

    所以,在这节课的最后,我们建议:【所有的授权许可类型中,授权码许可类型的安全性是最高的。因此,只要具备使用授权码许可类型的条件,我们一定要首先授权码许可类型。】

    2020-07-12
    1
收起评论
23
返回
顶部