ICode9
精准搜索请尝试： 精确搜索
首页
编程语言>
数据库
系统相关
互联网
其他分享
Python
Java
JavaScript
android
PHP
首页 > 其他分享> 文章详细

OAuth 2.0 扩展协议之 PKCE

2021-11-15 12:04:51  阅读：176  来源： 互联网

标签：code challenge verifier 服务器 PKCE OAuth 授权 2.0 客户端


前言

阅读本文前需要了解 OAuth 2.0 授权协议的相关内容， 可以参考我的上一篇文章 OAuth 2.0 的探险之旅。

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 协议流程

PKCE 协议本身是对 OAuth 2.0 的扩展， 它和之前的授权码流程大体上是一致的， 区别在于， 在向授权服务器的 authorize endpoint 请求时，需要额外的 code_challenge 和 code_challenge_method 参数， 向 token endpoint 请求时， 需要额外的 code_verifier 参数， 最后授权服务器会对这三个参数进行对比验证， 通过后颁发令牌。

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位的随机字符串。

javascript 示例

// 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));

java 示例

// 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);

c# 示例


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_challenge_method

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

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

code_challenge

使用 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 的值相等。

javascript 示例

// 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));

java 示例

// 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);

C# 示例

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

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 模式的授权过程

References

https://www.rfc-editor.org/rfc/rfc6749
https://www.rfc-editor.org/rfc/rfc7636.html
https://oauth.net/2/pkce
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04

标签：code,challenge,verifier,服务器,PKCE,OAuth,授权,2.0,客户端
来源： https://www.cnblogs.com/myshowtime/p/15555538.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

关于我们 | 联系我们 | 留言反馈

专注分享技术，共同学习，共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有