02 | 授权码许可类型中，为什么一定要有授权码？
为什么需要授权码？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
OAuth 2.0中的授权码许可类型在不同场景中的重要性和应用是本文的重点。文章首先介绍了OAuth 2.0的四种角色，并以小兔软件和京东商家开放平台为例，阐述了授权码许可类型的序列图。其次，文章分析了为什么需要授权码，以及授权码和访问令牌在第三方软件和授权服务之间的流转过程。进一步，通过分析授权码许可类型的通信过程，文章从间接通信和直接通信的维度来解释了授权码的获取和使用过程。文章还探讨了授权码许可流程不一定需要浏览器参与的情况，例如在微信小程序中的应用。总的来说，本文通过深入的技术分析，帮助读者理解了授权码许可类型的重要性和流程，为读者提供了对OAuth 2.0授权码许可类型的全面认识。文章内容涵盖了授权码许可类型的逻辑、通信方式、安全性要求以及不同应用场景，为读者提供了全面的技术视角和思考。
《OAuth 2.0 实战课》，新⼈⾸单¥29
全部留言(68)
- 最新
- 精选
小祺授权码被盗取后，人家不能也模拟服务器请求获取access_token吗？作者回复: 一方面授权码也都有有效期，另外一方面除非再盗取了第三方应用软件的app_id、secret才能成功请求资源。
2020-07-021459
mgxian如果使用HTTPS是不是可以不使用授权码？也能保证安全了作者回复: HTTPS 和 OAuth 是两个维度的安全，HTTPS解决的信息加密传输，OAuth 解决的是用token来代替用户名和密码传输。
2020-07-02627
马成老师，我觉得您文章中举的例子不能说明授权码的必要性，我举一个不需要授权码的例子： 1）小明访问浏览器，浏览器（前端）向小兔后台发起请求（这里是后天哦，不是直接向授权服务器）； 2）小兔后台和授权服务器做一次交互，拿到访问令牌； 3）小兔后台通过访问令牌获取的需要的资源（第二次交互） 4）小兔后台响应步骤1）的请求，返回结果页面 上面的例子，访问令牌并不会暴露给浏览器，但是也不需要授权码！ 所以我个人觉得，授权码的作用并不简单是为了让访问令牌不暴露在前台，这样设计的目的是： 1）专门为了增加一次用户可选择的交互。第一次访问一般是直接访问授权服务器的，所以第一次的返回页面是授权服务器给的，这里有两种选择，第一种是静默授权，直接302跳转；第二种就是给用户一个选择，让用户点击确认一下才会跳转到小兔后台。 2）第二个原因，因为访问令牌是很私密的东西，安全新考虑需要设置有效期，然而不可能每次获取都需要用户确认（这样用户体验太差了），所有授权码只需要一次，但是访问令牌的获取可能需要多次。 3）从授权服务器考虑，这里有两阶段授权，第一阶段使用授权码表示一次安全访问的开始；第二阶段只有第一次使用appkey获取访问令牌，后续只需要更换令牌，减少appkey在网络上传输的次数，直至本次安全访问结束，下次开始重新需要从授权码开始。作者回复: 感谢 马成 同学的细心学习。 OAuth 2.0 流程许可类型中有最基本的四种授权许可类型，授权码许可、客户端凭据许可、隐式许可、资源拥有者凭据许可，你举得那个例子，可以属于客户端凭据许可类型场景，不需要授权码。咱们这篇文章讲的授权码许可类型，所以谈到了授权码许可类型为什么要有授权码，为什么这么啰嗦再来一个步骤，而不是直接给访问令牌，直接给访问令牌的授权许可类型比如刚才说的客户端凭据许可类型。 1）【是为了增加一次用户可选择的交互】，这里呢，咱们文中也描述了“为了重新建立起这样的一次连接，我们又不能让访问令牌暴露出去，就有了这样一个临时的、间接的凭证：授权码。因为小兔软件最终要拿到的是安全保密性要求极高的访问令牌，并不是授权码，而授权码是可以暴露在浏览器上面的。这样有了授权码的参与，访问令牌可以在后端服务之间传输，同时呢【还可以重新建立小明与小兔软件之间的“连接”】。这样通过一个授权码，既“照顾”到了小明的体验，又“照顾”了通信的安全。” 2）安全性考虑访问令牌一定是要有有效期的，另外呢，重新获取令牌跟刷新令牌有关系，跟授权码就没有关系了。 3）授权只有一个阶段就是【颁发访问令牌】，其余的内容都是做准备工作。授权的本质并不是建设appkey传输的次数，而是为了【减少用户名和密码的传输次数】，以便减少“攻击面”，不用每次访问订单API、商品API等等，都带着用户名和密码。
2020-07-051421
陈钦成refresh_token存在的意义是什么？access_token过期了，为什么要用refresh_token去获取access_token，好像重新获取access_token也行作者回复: refresh_token 存在于授权码许可和资源拥有者凭据许可下 ，为了不烦最终用户频繁的点击【授权】按钮动作，才有了这样的机制； 在 隐式许可和客户端凭据许可，这两种许可类型下，不需要refresh_token，他们可以直接根据app_id和secret来换取访问令牌，因为，1-隐式许可对任何内容都是“透明的”，也没有必要存在refresh_token，2-客户端凭据许可，既然是叫做“客户端凭据”了，在获取那些没有跟用户强关联的信息的时候，比如 国家省市信息类似的信息，其实没有用户参与的必要性，当然可以随时获取令牌。
2020-07-021313- Geek_7c4953了解了OAuth2.0以后，就感觉本地登录不知道怎么做了。毕竟OAuth2.0有协议支撑，严谨安全，而且通用。但是小项目也搞个授权服务就有点小题大做。 所以，对于本地登录来说，是否可以套用OAuth2.0，需要做哪些方面的变通？又或者，是否有更合适的协议呢？
作者回复: OAuth 2.0 产生于第三方应用的场景，来管理对外的权限，但是它的本质思想是【用token来代替用户名和密码】。 对于我们内部的系统服务之间，我们可以借用OAuth 2.0的这种思想来满足我们的生产环境，比如微服务之间调用需要进行鉴权的时候，我们就可以使用这种token的机制。
2020-07-06212 - Pui不明白:把安全保密性要求极高的访问令牌暴露在浏览器上，请问如果把令牌暴露在前端会带来怎样的后果呢？
作者回复: 在后面的安全那讲中，我们也会强调这点，令牌一定要通过后端通信传输（其实也有授权许可是通过前端传输，比如隐式许可，但它是非常不安全的许可类型），我们强调OAuth 2.0的核心是令牌，不过，安全性是一个【组合性】的问题，单个信息暴露在公网一时是没有直接的问题，比如用户的手机号，被人知道了，一般情况下仅仅是被骚扰，但如果黑产拿到跟这个手机号更多关联的信息，比如订单信息，你买了什么商品都知道，这个时候用户就会有被恶意诈骗的可能。像这样的核心信息手机号也好，token也好肯定都是要重点保护的。
2020-07-0269 
秋克斯老师您好，有个疑惑，按照没有授权码，我们就只能把访问令牌发给软件小兔的后端服务，但是这样小兔和用户的连接就中断了。这里没明白，我们直接把访问令牌发送给小兔后端，由小兔后端重定向到小兔前端页面不就可以了？作者回复: 如果是按照直接把访问令牌给的小兔的后端，就会有这样的情况：小明访问小兔，小兔重定向到了授权服务页面，这个时候小明一种【停留】在了授权服务的页面上。 小明被重定向到授权服务之后，小明跟小兔之间的”连接断了“，也是这个意思。
2020-07-0456
Sath哥， 授权服务：“小兔软件，我把授权码发给浏览器了。” 这句话什么意思，没有get到浏览器的作用。麻烦解释一下哈😄作者回复: Web场景下，授权码code的值是在前端通信中完成的，也就是通信载体是 浏览器，再进一步说是通过重定向完成的，所以要返回到浏览器上，第三方软件-小兔软件，它通过这样的方式拿到了授权码code的值。
2020-07-0326
大秦皇朝王老师好~我想知道，如果，截获到了浏览器获取到的授权code，第一时间去授权服务换取token，这样不依旧存在风险？就是不知道会不会有这样的可能？如果有可能，那只是说通过授权码这种机制大大减少或者提高了盗取的成本，但从根本上没有解决这个安全问题呀？(前提假设是黑产已经提前获取了app_id和secret，因为我觉得有能力截取到code同样也有能力获取app_id和secret)作者回复: “有能力截取到code同样也有能力获取app_id和secret”，获取app_id和secret的难度是很大的，这些都是保存在第三方应用的服务器上面。
2020-07-0285
Wechat授权码暴露在浏览器的话，不也是可以拿到，然后操作用户数据吗？这和拿到access_token有什么区别。作者回复: OAuth 2.0的核心 归结两点的话，就是：生成access_token和使用access_token，受保护资源只能被允许使用access_token，不能被允许使用授权码。授权码仅仅是一个“中间值”。
2020-07-0253
