关于java:OAuth-20-扩展协议之-PKCE

大家好，我是本期的实验室研究员——等天黑。明天咱们的钻研对象是 OAuth 扩大协定 PKCE, 其中在 OAuth 2.1 草案中, 举荐应用 Authorization Code + PKCE 的受权模式, PKCE 为什么如此重要? 接下来就让咱们一起到实验室中一探到底吧！

PKCE 全称是 Proof Key for Code Exchange，在 2015 年公布，它是 OAuth 2.0 外围的一个扩大协定，所以能够和现有的受权模式联合应用，比方 Authorization Code + PKCE，这也是最佳实际，PKCE 最后是为挪动设施利用和本地利用创立的，次要是为了缩小公共客户端的受权码拦挡攻打。

在最新的 OAuth 2.1 标准中 (草案)，举荐所有客户端都应用 PKCE，而不仅仅是公共客户端，并且移除了 Implicit 隐式和 Password 模式，那之前应用这两种模式的客户端怎么办? 是的，您当初都能够尝试应用 Authorization Code + PKCE 的受权模式。那 PKCE 为什么有这种魔力呢? 实际上 它的原理是客户端提供一个自创立的证实给受权服务器，受权服务器通过它来验证客户端，把拜访令牌(access_token) 颁发给实在的客户端而不是伪造的。

下面说到了 PKCE 次要是为了缩小公共客户端的受权码拦挡攻打，那就有必要介绍下两种客户端类型了。

OAuth 2.0 外围标准定义了两种客户端类型，confidential 秘密的，和 public 公开的，辨别这两种类型的办法是，判断这个客户端是否有能力保护本人的机密性凭据 client_secret。

confidential
对于一个一般的 web 站点来说，尽管用户能够拜访到前端页面，然而数据都来自服务器的后端 api 服务，前端只是获取受权码 code，通过 code 换取 access_token 这一步是在后端的 api 实现的，因为是外部的服务器，客户端有能力保护明码或者密钥信息，这种是秘密的的客户端。
public
客户端自身没有能力保留密钥信息，比方桌面软件，手机 App，单页面程序(SPA)，因为这些利用是公布进来的，实际上也就没有平安可言，歹意攻击者能够通过反编译等伎俩查看到客户端的密钥，这种是公开的客户端。

在 OAuth 2.0 受权码模式（Authorization Code）中，客户端通过受权码 code 向受权服务器获取拜访令牌(access_token) 时，同时还须要在申请中携带客户端密钥(client_secret)，受权服务器对其进行验证，保障 access_token 颁发给了非法的客户端，对于公开的客户端来说，自身就有密钥泄露的危险，所以就不能应用惯例 OAuth 2.0 的受权码模式，于是就针对这种不能应用 client_secret 的场景，衍生出了 Implicit 隐式模式，这种模式从一开始就是不平安的。在通过一段时间之后，PKCE 扩大协定推出，就是为了解决公开客户端的受权平安问题。

下面是 OAuth 2.0 受权码模式的残缺流程，受权码拦挡攻打就是图中的 C 步骤产生的，也就是受权服务器返回给客户端受权码的时候，这么多步骤中为什么 C 步骤是不平安的呢? 在 OAuth 2.0 外围标准中，要求受权服务器的 anthorize endpoint 和 token endpoint 必须应用 TLS（平安传输层协定）爱护，然而受权服务器携带受权码 code 返回到客户端的回调地址时，有可能不受 TLS 的爱护，恶意程序就能够在这个过程中拦挡受权码 code，拿到 code 之后，接下来就是通过 code 向受权服务器换取拜访令牌 access_token，对于秘密的客户端来说，申请 access_token 时须要携带客户端的密钥 client_secret，而密钥保留在后端服务器上，所以恶意程序通过拦挡拿到受权码 code 也没有用，而对于公开的客户端（手机 App，桌面利用）来说，自身没有能力爱护 client_secret，因为能够通过反编译等伎俩，拿到客户端 client_secret，也就能够通过受权码 code 换取 access_token，到这一步，歹意利用就能够拿着 token 申请资源服务器了。

state 参数，在 OAuth 2.0 外围协定中，通过 code 换取 token 步骤中，举荐应用 state 参数，把申请和响应关联起来，能够避免跨站点申请伪造 -CSRF 攻打，然而 state 并不能避免下面的受权码拦挡攻打，因为申请和响应并没有被伪造，而是响应的受权码被恶意程序拦挡。

PKCE 协定自身是对 OAuth 2.0 的扩大，它和之前的受权码流程大体上是统一的，区别在于，在向受权服务器的 authorize endpoint 申请时，须要额定的 code_challenge 和code_challenge_method参数，向 token endpoint 申请时，须要额定的 code_verifier 参数，最初受权服务器会对这三个参数进行比照验证，通过后颁发令牌。

对于每一个 OAuth 受权申请，客户端会先创立一个代码验证器 code_verifier，这是一个高熵加密的随机字符串，应用 URI 非保留字符 (Unreserved characters)，范畴 [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"，因为非保留
字符在传递时不须要进行 URL 编码，并且 code_verifier 的长度最小是 43，最大是 128，code_verifier 要具备足够的熵它是难以猜想的。

code_verifier 的裁减巴科斯范式 (ABNF) 如下:

code-verifier = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39

简略点说就是在[A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" 范畴内，生成 43-128 位的随机字符串。

// Required: Node.js crypto module
// https://nodejs.org/api/crypto.html#crypto_crypto
function base64URLEncode(str) {return str.toString('base64')
        .replace(/\+/g，'-')
        .replace(/\//g，'_')
        .replace(/=/g，'');
}
var verifier = base64URLEncode(crypto.randomBytes(32));

// Required: Apache Commons Codec
// https://commons.apache.org/proper/commons-codec/
// Import the Base64 class.
// import org.apache.commons.codec.binary.Base64;
SecureRandom sr = new SecureRandom();
byte[] code = new byte[32];
sr.nextBytes(code);
String verifier = Base64.getUrlEncoder().withoutPadding().encodeToString(code);


public static string randomDataBase64url(int length)
{RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
    byte[] bytes = new byte[length];
    rng.GetBytes(bytes);
    return base64urlencodeNoPadding(bytes);
}

public static string base64urlencodeNoPadding(byte[] buffer)
{string base64 = Convert.ToBase64String(buffer);
    base64 = base64.Replace("+"，"-");
    base64 = base64.Replace("/"，"_");
    base64 = base64.Replace("="，"");
    return base64;
}

string code_verifier = randomDataBase64url(32);

对 code_verifier 进行转换的办法，这个参数会传给受权服务器，并且受权服务器会记住这个参数，颁发令牌的时候进行比照，code_challenge == code_challenge_method(code_verifier)，若统一则颁发令牌。

code_challenge_method 能够设置为 plain(原始值)或者 S256(sha256 哈希)。

应用 code_challenge_method 对 code_verifier 进行转换失去 code_challenge，能够应用上面的形式进行转换

plain
code_challenge = code_verifier
S256
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

客户端应该首先思考应用 S256 进行转换，如果不反对，才应用 plain，此时 code_challenge 和 code_verifier 的值相等。

// Required: Node.js crypto module
// https://nodejs.org/api/crypto.html#crypto_crypto
function sha256(buffer) {return crypto.createHash('sha256').update(buffer).digest();}
var challenge = base64URLEncode(sha256(verifier));

// Dependency: Apache Commons Codec
// https://commons.apache.org/proper/commons-codec/
// Import the Base64 class.
// import org.apache.commons.codec.binary.Base64;
byte[] bytes = verifier.getBytes("US-ASCII");
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(bytes，0，bytes.length);
byte[] digest = md.digest();
String challenge = Base64.encodeBase64URLSafeString(digest);

public static string base64urlencodeNoPadding(byte[] buffer)
{string base64 = Convert.ToBase64String(buffer);
    base64 = base64.Replace("+"，"-");
    base64 = base64.Replace("/"，"_");
    base64 = base64.Replace("="，"");
    return base64;
}
[InternetShortcut]
URL=https://segmentfault.com/a/1190000041093435/edit###

string code_challenge = base64urlencodeNoPadding(sha256(code_verifier));

下面咱们说了受权码拦挡攻打，它是指在整个受权流程中，只须要拦挡到从受权服务器回调给客户端的受权码 code，就能够去受权服务器申请令牌了，因为客户端是公开的，就算有密钥 client_secret 也是形同虚设，恶意程序拿到拜访令牌后，就能够光明磊落的申请资源服务器了。

PKCE 是怎么做的呢? 既然固定的 client_secret 是不平安的，那就每次申请生成一个随机的密钥（code_verifier），第一次申请到受权服务器的 authorize endpoint 时，携带 code_challenge 和 code_challenge_method，也就是 code_verifier 转换后的值和转换方法，而后受权服务器须要把这两个参数缓存起来，第二次申请到 token endpoint 时，携带生成的随机密钥的原始值 (code_verifier)，而后受权服务器应用上面的办法进行验证:

plain
code_challenge = code_verifier
S256
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

通过后才颁发令牌，那向受权服务器 authorize endpoint 和 token endpoint 发动的这两次申请，该如何关联起来呢? 通过受权码 code 即可，所以就算恶意程序拦挡到了受权码 code，然而没有 code_verifier，也是不能获取拜访令牌的，当然 PKCE 也能够用在秘密（confidential）的客户端，那就是 client_secret + code_verifier 双重密钥了。

最初看一下申请参数的示例:

GET /oauth2/authorize 
https://www.authorization-server.com/oauth2/authorize?
response_type=code
&client_id=s6BhdRkqt3
&scope=user
&state=8b815ab1d177f5c8e 
&redirect_uri=https://www.client.com/callback
&code_challenge_method=S256 
&code_challenge=FWOeBX6Qw_krhUE2M0lOIH3jcxaZzfs5J4jtai5hOX4

POST /oauth2/token  
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

https://www.authorization-server.com/oauth2/token?
grant_type=authorization_code
&code=d8c2afe6ecca004eb4bd7024
&redirect_uri=https://www.client.com/callback
&code_verifier=2D9RWc5iTdtejle7GTMzQ9Mg15InNmqk3GZL-Hg5Iz0

下边应用 Postman 演示了应用 PKCE 模式的受权过程。

https://www.rfc-editor.org/rf…
https://www.rfc-editor.org/rf…
https://oauth.net/2/pkce
https://datatracker.ietf.org/…

微软最有价值专家（MVP）

微软最有价值专家是微软公司授予第三方技术专业人士的一个寰球奖项。28 年来，世界各地的技术社区领导者，因其在线上和线下的技术社区中分享专业知识和教训而取得此奖项。

MVP 是通过严格筛选的专家团队，他们代表着技术最精湛且最具智慧的人，是对社区投入极大的激情并乐于助人的专家。MVP 致力于通过演讲、论坛问答、创立网站、撰写博客、分享视频、开源我的项目、组织会议等形式来帮忙别人，并最大水平地帮忙微软技术社区用户应用 Microsoft 技术。
更多详情请登录官方网站：
https://mvp.microsoft.com/zh-cn

欢送关注微软中国 MSDN 订阅号，获取更多最新公布！

关于java:OAuth-20-扩展协议之-PKCE

前言

客户端类型

受权码拦挡攻打

PKCE 协定流程

code_verifier

javascript 示例

java 示例

c# 示例

code_challenge_method

code_challenge

javascript 示例

java 示例

C# 示例

原理剖析

参考文献