OAuth 2.1
去掉了
OAuth2.0
中的密码模式、简化模式，增加了设备授权码模式，同时也对授权码模式增 加了PKCE
扩展。
授权码模式+PKCE扩展
授权码模式交互过程，见之前
OAuth2.0
授权码模式的讲解。这里要说的是授权码模式如何拓展
PKCE
（
Proof Key for Code Exchange
）。
在授权码模式的交互工程中，有一个环节比较薄弱，这个环节就是用户在代理页面确认授权的时候，
容易受到恶意程序的攻击，从而导致授权码被恶意程序窃取，进而通过授权码窃取令牌，当然这个前
提也需要恶意程序已经植入到你的
PC
或手机当中。首先，来看一下官网中描述的恶意程序拦截攻击授
权码的交互图：
（
1
）客户端向认证服务器发起获取授权码请求时，跳转至授权确认页面，用户通过用浏览器在授权页 面进行授权确认。
（
2
）授权页面向认证服务器提交客户端参数和授权范围。
（
3
）认证服务器将授权码拼接在客户端注册的回调地址中返回给客户端。
（
4
）在步骤（
3
）认证服务器返回授权码的过程中，如果恶意程序截取到授权码，那么他接下来就可 以继续操作步骤（5
）、步骤（
6
）了。
为了减轻这种攻击，官方增加
PKCE
扩展，先来看一下官方的交互图：
A.
客户端通过
“/oauth2/authorize”
地址向认证服务器发起获取授权码请求的时候增加两个参数，即
code_challenge
和
code_challenge_method
，其中，
code_challenge_method
是加密方法（例如： S256 或
plain
），
code_challenge
是使用
code_challenge_method
加密方法加密后的值。
B.
认证服务器给客户端返回授权码，同时记录下
code_challenge
、
code_challenge_method
的值。
C.
客户端使用
code
向认证服务器获取
Access Token
的时候，带上
code_verifier
参数，其值为步骤
A 加密前的初始值。
D.
认证服务器收到步骤
C
的请求时，将
code_verifier
的值使用
code_challenge_method
的方法进行 加密，然后将加密后的值与步骤A
中的
code_challenge
进行比较，看看是否一致。
上面交互过程中，恶意程序如果在
B
处截获授权码后，使用授权码向认证服务器换取
AccessToken
， 但由于恶意程序没有 code_verifier
的值，因此在认证服务器无法校验通过，从而获取
Access Token 失败。
设备授权码模式
设备授权码模式，是一种为解决不便在当前设备上进行文本输入而提供的一种认证授权模式，例如：
智能电视、媒体控制台、数字相框、打印机等
扫一扫
2958
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
