上一篇文章介绍了 OAuth 2.0 是一种授权机制，主要用来颁发令牌（token）。本文接着介绍颁发令牌的实务操作。
下面我假定，你已经理解了 OAuth 2.0 的含义和设计思想，否则请先阅读这个系列的上一篇文章。
进入正文之前，插播一则活动消息。
4月22日（周一）到4月29日（下周一），每天晚上八点都有两小时的免费直播课，体系化介绍高级前端开发知识，网易云课堂主办。详细介绍请看本文结尾，欢迎关注。
RFC 6749
OAuth 2.0 的标准是 RFC 6749 文件。该文件先解释了 OAuth 是什么。
OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。......资源所有者同意以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据。
这段话的意思就是，OAuth 的核心就是向第三方应用颁发令牌。然后，RFC 6749 接着写道：
（由于互联网有多种场景，）本标准定义了获得令牌的四种授权方式（authorization grant ）。
也就是说，OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。下面就是这四种授权方式。
- 授权码（authorization-code）
- 隐藏式（implicit）
- 密码式（password）：
- 客户端凭证（client credentials）
注意，不管哪一种授权方式，第三方应用申请令牌之前，都必须先到系统备案，说明自己的身份，然后会拿到两个身份识别码：客户端 ID（client ID）和客户端密钥（client secret）。这是为了防止令牌被滥用，没有备案过的第三方应用，是不会拿到令牌的。
第一种授权方式：授权码
授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。
这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。
第一步，A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。
https://b.com/oauth/authorize? response_type=code& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
上面 URL 中，response_type参数表示要求返回授权码（code），client_id参数让 B 知道是谁在请求，redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是只读）。
第二步，用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。
https://a.com/callback?code=AUTHORIZATION_CODE
上面 URL 中，code参数就是授权码。
第三步，A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。
https://b.com/oauth/token? client_id=CLIENT_ID& client_secret=CLIENT_SECRET& grant_type=authorization_code& code=AUTHORIZATION_CODE& redirect_uri=CALLBACK_URL
上面 URL 中，client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址。
第四步，B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。
{ "access_token":"ACCESS_TOKEN", "token_type":"bearer", "expires_in":2592000, "refresh_token":"REFRESH_TOKEN", "scope":"read", "uid":100101, "info":{...} }
上面 JSON 数据中，access_token字段就是令牌，A 网站在后端拿到了。
第二种方式：隐藏式
有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。
第一步，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。
https://b.com/oauth/authorize? response_type=token& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
上面 URL 中，response_type参数为token，表示要求直接返回令牌。
第二步，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。
https://a.com/callback#token=ACCESS_TOKEN
上面 URL 中，token参数就是令牌，A 网站因此直接在前端拿到令牌。
注意，令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。
这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。
第三种方式：密码式
如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。
第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌。
https://oauth.b.com/token? grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID
上面 URL 中，grant_type参数是授权方式，这里的password表示"密码式"，username和password是 B 的用户名和密码。
第二步，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。
这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。
第四种方式：凭证式
最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。
第一步，A 应用在命令行向 B 发出请求。
https://oauth.b.com/token? grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让 B 确认 A 的身份。
第二步，B 网站验证通过以后，直接返回令牌。
这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。
令牌的使用
A 网站拿到令牌以后，就可以向 B 网站的 API 请求数据了。
此时，每个发到 API 的请求，都必须带有令牌。具体做法是在请求的头信息，加上一个Authorization字段，令牌就放在这个字段里面。
curl -H "Authorization: Bearer ACCESS_TOKEN" \ "https://api.b.com"
上面命令中，ACCESS_TOKEN就是拿到的令牌。
更新令牌
令牌的有效期到了，如果让用户重新走一遍上面的流程，再申请一个新的令牌，很可能体验不好，而且也没有必要。OAuth 2.0 允许用户自动更新令牌。
具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。
https://b.com/oauth/token? grant_type=refresh_token& client_id=CLIENT_ID& client_secret=CLIENT_SECRET& refresh_token=REFRESH_TOKEN
上面 URL 中，grant_type参数为refresh_token表示要求更新令牌，client_id参数和client_secret参数用于确认身份，refresh_token参数就是用于更新令牌的令牌。
B 网站验证通过以后，就会颁发新的令牌。
写到这里，颁发令牌的四种方式就介绍完了。下一篇文章会编写一个真实的 Demo，演示如何通过 OAuth 2.0 向 GitHub 的 API 申请令牌，然后再用令牌获取数据。
（正文完）
前端高级开发工程师免费直播课
经过多年的发展，前端工程师的地位日益提升，越来越多的人想往前端的方向发展。
但是，市场对前端工程师的要求也越来越高，深入掌握底层技术的高级前端，才能在市场上找到自己立足之地。
为了帮助大家深入了解高级前端的学习要点，4月22日（周一）到4月29日（下周一），网易云课堂推出了前端进阶免费直播课。
- 周一（4月22日）：《前端不会点 node 怎么行，node http 模块详解》
- 周二（4月23日）：《进阶面试必备的三大技术题》
- 周三（4月24日）：《前端高级工程师核心装备之柯里化》
- 周四（4月25日）：《手把手带你实现 Vue 的 MVVM》
- 周五（4月26日）：《JQuery 原理分析》
- 周六（4月27日）：《用迭代器模式让你的脱离繁重的数据处理 》
- 周日（4月28日）：《前端性能--JS的防抖节流实现与案例场景》
- 周一（4月29日）：《阿里巴巴 P5 面试题讲解》
（更多介绍点击这里）
他们邀请了网易资深前端工程师，免费直播分享实战中的经验方法。内容涉及网易内部自定组件库工具分享，前端开发相关知识，深度剖析 JavaScript 等。
这个直播面向前端初、中级开发工程师，每天2个小时，都是一些干货分享并且不收费，建议想进阶的同学坚持学习。大家可以微信扫码，添加助教，获取听课地址。
（完）
chrisyue 说：
Implicit Flow 返回 access token 时，不应该用 query (?token=TOKEN-xxx) 而是 fragment (#TOKEN-xxx)
这在 RFC 6749 里是有规定的 https://tools.ietf.org/html/rfc6749#section-4.2
在 implicit 中使用 fragment 传递 token 是很巧妙的设计，具体原因可见：https://www.chrisyue.com/?p=3178
2019年4月 9日 11:28 | # | 引用
阮一峰 说：
@chrisyue：
谢谢指出，这一点真没注意到，涨知识了。我一会就把原文改掉。
2019年4月 9日 11:49 | # | 引用
Ceniy 说：
Demo 会使用 vue 和axios吗？ 还是原始的ajax，最近正好碰到这个问题了，token过期后，底层需要能自动去刷新token，还得避免 有多个并发请求的时候，会不会导致这些请求同时都在进行刷新token ？
2019年4月 9日 14:26 | # | 引用
skywalker 说：
阮老师写的通俗易懂
2019年4月 9日 15:52 | # | 引用
kergee 说：
单点登录一般采用哪种比较多？
2019年4月 9日 19:22 | # | 引用
coderlim 说：
授权码方式，前端去后端拿了一个授权码，然后拿着授权码再去后端拿令牌，授权码和令牌都是后端产生的，为什么这种方式比直接拿令牌安全呢？
2019年4月10日 10:07 | # | 引用
LouXudong 说：
因为获取授权码的方式是通过浏览器跳页(get请求)，返回的授权码展示在地址栏，安全性不高。而获取令牌可以使用post请求。另外，因为授权码与发起请求的URL是关联的，所以另一个网站使用你的授权码是无法成功得到令牌的。
2019年4月10日 18:41 | # | 引用
DanielDuan 说：
请问一下：A网站拿到B网站颁发的令牌后，是否直接将token返回给访问A网站的浏览器？如果是，当用户再次通过浏览器、携带token访问A网站的时候，A如何校验该令牌是否有效呢？A网站的后端会保存B网站之前返回的token，然后直接比较是否相等，还是A网站携带浏览器发出的token，去B网站校验？
2019年4月17日 21:51 | # | 引用
wangyifei 说：
首先作者说的获取令牌有多种方式，如果是通过授权码，令牌是发到A后台的，如果是隐藏式，那么是发到前端的，也就是给浏览器的。这个token是B产生的，当然是在访问B资源的时候在B验证
2019年4月18日 17:09 | # | 引用
wangyifei 说：
授权码是B应用用来验证A应用的请求是经过用户登陆验证的
2019年4月18日 18:08 | # | 引用
Sky、Memory 说：
第一种授权方式里面，获取access_token时带上的redirect_uri参数，RFC 6749里面的解释是拿来做验证的，具体可见: https://tools.ietf.org/html/rfc6749#section-4.1
2019年4月24日 21:14 | # | 引用
Chenyang 说：
是不是意味着A网站持有用户授权过的B网站access token和refresh token的话，自身不需要用户再次授权就可以一直访问B网站上的资源.
2019年5月 1日 20:45 | # | 引用
咔咔咔 说：
老师你好 如果要做一个api平台 ,做成两个系统 , 一个是后台系统 给用户授权可用的接口 一个是客户访问的系统 后台系统管理员授权之后 客户可以调用已授权的接口 , 这种应用场景 适用于哪种授权模式呢? 请老师指教一下
2019年5月 8日 10:28 | # | 引用
dechy 说：
用户对什么资源进行授权，这里并没有体现出来。客户端想要获取用户的资源可能是各种各样的，而认证的流程是一样的。
是不是应该有参数让客户端指定获取用户哪方面的资源呢？
2019年5月22日 20:13 | # | 引用
thomas 说：
嗯呢，不错，很容易的就了解了登录授权机制
但是我有一个问题，我从YouTobe的视频APP中分享视频到Twitter APP中，却可以直接唤起Twitter APP，并没有经过登录与授权的步骤，这会是神马原因呢？
2019年5月31日 16:39 | # | 引用
Alex 说：
建议微信文档直接链接此文章, 清晰多了
2019年6月11日 18:31 | # | 引用
pangtu 说：
关于授权码模式的疑问：
文中写到“第四步，B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据”
问题是：既然是后端获取，我理解应该直接是A在后端拿到code后直接带着授权码发请求给B，B直接响应给A token就可以了
但是为什么是B又多了一道子，b在请求redirct_uri，向这个地址发送请求给A，A在接收token。
2019年6月12日 12:55 | # | 引用
wenxin667 说：
不一样，这里面有三者参与：A_C【浏览器】、B_S【授权中心】、A_S【网站A的后端】
A_C 先去与 B_S 交互，拿到 code
然后code 给A_S
A_S 与 B_S 交互，拿到 Token。 Token 不会暴露给 A_C
【我的疑惑在于，难道之后A_C 请求用户 在B_S 的个人数据，都需要 经过A_S的中转吗？】
2019年6月17日 17:48 | # | 引用
wenxin667 说：
1、授权码的方式：
为了保证令牌的不泄露，是否所有的A浏览器 向B请求数据，都需要 经过 A的后端去转发呢？
2、隐藏式：
看文中的例子，似乎没有向B提供密码呢？难道纯前端的应用，无须向B备案，无须密码就可以直接获取令牌吗？
3、凭证式：
关于凭证式没有理解到何为 针对第三方应用？而且 密码也是直接暴露在A端的了吗？
2019年6月17日 18:34 | # | 引用
wenxin667 说：
突然想通了 1、令牌就是要暴露出去的，而不用暴露出去的是 A的后端的 secret
2019年6月17日 18:36 | # | 引用
jk2k 说：
@wenxin667：
文章里应该写错了，redirect_uri参数 只是用来验证是否有效，authorization server 会直接响应 access_token 数据
2019年6月26日 16:55 | # | 引用
天亮前说晚安 说：
其实我想知道点击同意授权，B的客户端做了什么？看了很多篇，都有点蒙蒙的，觉得没讲明白是因为：没说明白哪部分是第三方应用客户端做的，还是第三方应用服务端做的。
2019年7月16日 17:38 | # | 引用
天亮前说晚安 说：
第一步的clientid 是B的客户端id还是A的客户端id啊？
2019年7月16日 17:41 | # | 引用
Xanthuim 说：
大佬能讲一讲access_token前面的Bearer是啥意思吗？
2019年7月22日 13:10 | # | 引用
seaver 说：
是 A 网站的。因为之前 A 网站要在授权服务器那注册，会被分配一个 id。后面去交互时候要带上 id 来标识自己身份。
2019年8月 9日 09:57 | # | 引用
navy 说：
为了进一步保证安全，即使你拿到了 A 的 AUTHORIZATION_CODE、client_i，甚至client_secret，但你没有控制 A 的网站，你依然拿不到 access_token。access_token只发向已经在 B 注册的域名。
2019年8月22日 10:25 | # | 引用
黑鸦 说：
授权码模式，token只存在后端的话，那同一用户每次访问资源，后端如何辨别出该用户对应的token呢？
2019年8月30日 09:40 | # | 引用
anne 说：
老师，看了你的文章对oauth2有了基本的了解。多谢！
另外，我想请教使用vue前端+springboot后台如何实现授权码登录认证，不知道该怎么跳转？
2019年10月22日 18:05 | # | 引用
DaemonSu 说：
第二种认证方式最后有这样一段话：
这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。
这个session是B的session还是A的呢。如果是用户在A中的sessison，那么session是否终结B应用应该是不知道的。反之亦然。所以，对session失效令牌就失效了这句话感到不理解，希望老师能够讲解下
2019年10月29日 18:52 | # | 引用
沁园 说：
client secret 是在什么时候进行校验的呢？按照文中的协议，似乎 client id 很容易就被盗用，因为从头到尾都没有校验 client secret
2020年1月25日 19:19 | # | 引用
遗忘 说：
授权码方式有点疑问，拿使用微信小程序来说，用户A想使用小程序B的功能，需要一个微信用户中心C的授权码，实际用户A只是拿C给的授权码访问小程序B的资源，这个场景好像和楼主说的不一样吧？后续用户A是使用授权码访问小程序B的资源，其实任何人都可以使用A的授权码都可以访问B
2020年3月18日 09:52 | # | 引用
He.Chun 说：
寫的太棒了!
想請問一下，文中的
https://b.com/oauth/token?
https://oauth.b.com/token?
這兩個url我可以想成是同一個url嗎
2020年4月15日 14:09 | # | 引用
Heropoo 说：
一直收藏着，今天又看了一遍
2020年4月29日 14:03 | # | 引用
Junlong 说：
当使用授权码模式的时候，不向提供第三方应用的用户名和密码怎么知道用户的身份？
2020年5月15日 16:15 | # | 引用
randyfield 说：
说明你没有看懂文章，
不管哪一种授权方式，第三方应用申请令牌之前，都必须先到系统备案，说明自己的身份，然后会拿到两个身份识别码：
- 客户端 ID（client ID）
- 客户端密钥（client secret）
2020年6月24日 15:59 | # | 引用
yexiaoqian 说：
第一种授权码，是不是就是适用于好像微信这种登录第三方网站，第三种密码式的，是不是就适用于一般项目凭密码登录这种
2020年7月20日 11:10 | # | 引用
GY 说：
这种方式是最常用的流程，安全性也最高，”它适用于那些有后端的 Web 应用“。授权码通过前端传送，”令牌则是储存在后端“，而且所有与资源服务器的通信都在后端完成。
”它适用于那些有后端的 Web 应用“ 和 ”令牌则是储存在后端“ 这两句话是不是前后矛盾了
2020年7月27日 12:01 | # | 引用
Jacklondon Chen 说：
单点登录系统，有商业产品，也有开源软件产品。
国外的，IBM 有相关软件产品，价格未知；
国内的上海折桂软件也有一款软件产品，价格未知；
开源免费的有 CAS , 文档都是英文的，啃起来要花一点时间。
比较早期的有 Netscape 公司、Sun 公司，都推出过相应的软件，不值得公司被收购后还是否继续维护与销售。
2020年8月 4日 10:36 | # | 引用
Jacklondon Chen 说：
您所理解的“资源”，与 OAuth 概念中的资源，可能不是一回事。
举例来说，用户 Tom 用 IE 访问 sohu 网站，假定 sohu 网站支持 qq 账号，然后 sohu 网站将用户 IE 自动重定向到 qq 网站，让他用户录入密码进行登录、并勾选"允许 sohu 网站查看我的 qq 基本信息(qq号、性别等)"。
用户在 qq 网站登录完成(完成录入密码、完成勾选允许...)，qq 网站将用户 IE 自动重定向回 sohu 网站并给一个授权码, sohu 网站后台使用授权码，向 qq 网站索要 token；sohu 网站得到 token 后，向qq 网站索要当前 IE 远端用户的 qq 基本信息(qq号、性别等)。
之后 sohu 网站标记此 qq 用户为"本网站已登录、已注册用户"，允许sohu 网站访问本网站的内容(论坛等)。
OAuth 所说的"资源"，是登录网站的qq 基本信息(qq号、性别等), 不是指 sohu 网站的内容(论坛等).
2020年8月 4日 10:49 | # | 引用
Jacklondon Chen 说：
用户不访问资源(比如，qq 基本信息)，后端应用(比如，sohu网站)才访问资源。而且，后端应用，只访问一次资源。
后端应用(比如，sohu网站)自行维护 http session id 与 token 关系。每次用户 IE 访问后端应用(比如，sohu网站)，一段时间内，都会带同一个 http session id 的。
2020年8月 4日 10:58 | # | 引用
Jacklondon Chen 说：
access token和refresh token 都有有效期。
再说，这里的资源，一般仅仅指单个用户账号的信息(不包含密码)，访问一次就行了，没必要"一直访问"。另外，只能读、不能写，也做不了什么坏事。
2020年8月 4日 11:06 | # | 引用
jason 说：
什么是没有后端的纯前端应用？
2020年9月 9日 18:08 | # | 引用
conorzhong 说：
比如说浏览器插件
2020年11月 4日 09:42 | # | 引用
Polar 说：
想问一下，您这介绍的我可以理解为是opendId＋Auth2.0的方式吗
2021年1月14日 10:16 | # | 引用
hanszhao 说：
建议看看第三方应用使用微信登录的授权过程，这个授权过程就是微信基于OAuth2.0的第一种授权码的方式实现的，微信开放平台中的这方面的文档详细说明了整个过程，对理解授权码方式很有帮助。
2021年2月26日 10:34 | # | 引用
女武神 说：
@Jacklondon Chen：
请问，那如果sessionid被伪造了该怎么办呢
2021年3月22日 18:07 | # | 引用
凌培勇 说：
授权码方式
第四步，B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。
这个不一定会走重定向的方式，默认是直接返回JSON 数据的
org.springframework.security.oauth2.provider.endpoint.TokenEndpoint#postAccessToken
最后一行方法是 return getResponse(token);
该私有方法实现如下：
private ResponseEntity<OAuth2AccessToken> getResponse(OAuth2AccessToken accessToken) {
HttpHeaders headers = new HttpHeaders();
headers.set("Cache-Control", "no-store");
headers.set("Pragma", "no-cache");
headers.set("Content-Type", "application/json;charset=UTF-8");
return new ResponseEntity(accessToken, headers, HttpStatus.OK);
}
2021年7月 5日 11:34 | # | 引用
小七 说：
感觉听君一席话，胜读十年书。
2021年11月18日 13:59 | # | 引用
弋痕夕 说：
隐藏式 和 密码式 看文章中的例子，都没有使用到客户端密钥（client secret）。是不需要么？如果不需要原因是什么？是因为信息都出现在URL明文了，所以加不加无所谓么？
2021年11月24日 16:11 | # | 引用
wqs 说：
上面 URL 中，client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址。
========
这里为啥后端发请求就默认安全呢？这个中间人拿到数据后不也可以变相获取到令牌access_token么
2021年12月 7日 16:29 | # | 引用
durian 说：
@wqs：
后端存储的secret一般在服务器中，别人拿不到，并且Oauth的授权服务器一般采用的是HTTPS，可以防止中间人攻击。
2021年12月27日 15:59 | # | 引用
手中沙 说：
就以第一种为例，获取到code之后，到了A网站的服务端，就要通过code+clientid+clientSecret去获取accesstoken
2022年1月12日 11:51 | # | 引用
Colin 说：
Bearer 是token type。但是我不知道为啥是这个名字，而不是其他名字。
2022年2月 9日 17:49 | # | 引用
ZhiWang 说：
授权码（authorization-code）
隐藏式（implicit）
密码式（password）：
客户端凭证（client credentials）
其中第三行可以去掉 : 吗? 前端排版挺别致哈哈哈
2022年4月 8日 16:26 | # | 引用
ermo 说：
通俗易懂，每种情况的使用场景也很明确
2022年7月 1日 13:34 | # | 引用
cai 说：
必须给你点个赞，解惑了，这里阮一峰没讲清楚
2022年9月28日 10:16 | # | 引用
laoz 说：
感谢阮老师的写作，您的文章写得非常易懂，让新手也可以快速领会，比一些其他博客的文章强太多了！
2022年11月29日 22:24 | # | 引用
Robbinson 说：
最后一段 更新令牌(refresh token)的请求中，CLIENT_ID和 CLIENT_SECRET 是 用户的 信息还是 网站 A的信息。
2022年12月 5日 21:09 | # | 引用
Fatbean 说：
这里的CLIENT_ID和CLIENT_SECRET在微信开放平台就是appid和appsecret，是网站A的开发者在网站B（如微信）的开放平台预先登记后得到的，和具体用户无关。
2023年4月 3日 10:50 | # | 引用
寂寞姜大虎 说：
说得对，A网站后端请求B网站获取access_token，B网站直接通过response就返回给A网站的后端了。 而不用再转发到redirect_uri.
2023年11月20日 13:52 | # | 引用
ye 说：
1.**授权码的安全性**：授权码模式下，重定向的URL中只包含授权码，然后由客户端对应的后端服务带着授权码和授权服务器交换令牌：
授权码通常在交换过令牌后就会时效，且时效是非常短的。
2.**交换过程的安全性**：后端服务带着授权码和授权服务器交换令牌。交换令牌的过程后端服务还需要提供客户端id和密钥，而密钥通常是安全的，授权服务器可以通过校验密钥提供额外的安全保证。
综上，授权码即使泄露，也通常无法交换到令牌，因此我们认为授权码模式是安全的。
2024年5月30日 09:55 | # | 引用
一杯哈希不加盐 说：
有一个严重的错误：第一种授权方式（授权码 authorization code 方式）第三、四步使用授权码（code）获取令牌（token），B 提供的接口中，redirect_uri 参数仅用于校验，token 不会通过这个地址回调，而是作为 http response 直接返回
2024年9月 5日 19:17 | # | 引用