当前位置: 首页 > news >正文

OAuth2.1的code_challenge和code_vertifier理解

以下来自人工自能的回答。

OAuth 2.0 提供了多种授权模式,其中授权码模式(Authorization Code Grant)是最常用和最安全的一种。而 code_challenge 是该模式中的一个安全增强特性,主要用于 PKCE(Proof Key for Code Exchange)机制。

什么是 PKCE?

PKCE(Proof Key for Code Exchange)是一种扩展,旨在提高 OAuth 2.0 授权码模式的安全性,特别是当授权码在公共客户端(如运行在浏览器中的 JavaScript 应用或移动应用)中使用时。PKCE 通过在授权请求中添加一个额外的验证步骤来防止授权码被拦截和滥用。

code_challenge 的作用

code_challenge 是 PKCE 机制的一部分,它在授权请求阶段生成并发送。它基于一个秘密值(称为 code_verifier),通过一种散列算法(如 S256)进行变换得到。code_challenge 的目的是在不直接暴露 code_verifier 的情况下,为后续的令牌请求提供一个验证基础。

code_challenge 和 code_verifier 的生成与使用

  1. 生成 code_verifier
    code_verifier 是一个高熵、随机生成的字符串,通常至少为 128 位(即 16 字节)长,并且建议使用字母数字字符以及 -._~+/ 字符集中的字符。

  2. 生成 code_challenge
    使用 code_verifier,通过一种散列算法(如 S256)生成 code_challenge。对于 S256,code_challenge 是 code_verifier 的 SHA-256 哈希值的 Base64 URL 编码,但要去掉编码中的 = 填充字符,并且确保输出的长度是 43 个字符(由于 Base64 URL 编码后每 4 个字符代表 3 个字节,但最后一个字符块可能不足 4 个字符,所以去掉 = 后长度可能略有变化)。

  3. 在授权请求中使用 code_challenge
    在发起授权请求时,将 code_challenge 作为请求参数之一发送给授权服务器。

  4. 在令牌请求中使用 code_verifier
    当授权服务器返回授权码后,客户端使用这个授权码以及之前生成的 code_verifier 向令牌端点请求访问令牌。授权服务器将验证 code_challenge 和 code_verifier 是否匹配,从而确保请求是由原始客户端发起的。

示例

假设 code_verifier 是 dBjftJeZ4CVP-mB92K27uhbUX6vhSWQ,那么对应的 code_challenge(使用 S256)将是 E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstxsMPk


个人理解:

1. code_verifier是随机生成的字符串,基于这个字符串使用散列算法(S256)生成code_challenge。通过code_challenge是很难猜测计算得到code_verifier的。下面是授权码模式的认证流程。

code_chanllenge和code_verifier是网站W生成的,在第2步发送给浏览器的重定向url中设定code_challenge。例如:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&code_challenge=6fdkQaPm51l13DSukcAH3Mdx7_ntecHYd1vi3n0hMZY&code_challenge_method=S256 HTTP/1.1
Host: server.example.com

2. 在第8步之前,认证服务器生成授权码,会记录下code_challenge和授权码的成对关系。

3. 在第10步,当网站W拿着授权码去认证中心获取Token时,会把code_verifier带上。例如:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencodedgrant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed

总结:

这一套机制是为了确保拿着授权码来获取token的客户端,是当时当时认证服务器把授权码颁发给的对象。


http://www.mrgr.cn/news/48514.html

相关文章:

  • 五子棋项目自动化测试
  • 电脑无线网wifi和有线网同时使用(内网+外网同时使用)
  • 【Linux 从基础到进阶】防止数据泄露的策略与工具
  • 【WebGIS】Cesium:天地图加载
  • 每日OJ题_牛客_比那名居的桃子_滑动窗口/前缀和_C++_Java
  • C语言—双链表
  • 科大讯飞嵌入式面试题及参考答案
  • c++ 多线程全局变量安全操作------原子操作
  • 网工内推 | 初级网工,Base北京,IE认证优先,最高14K+餐补
  • Feign的使用
  • 【专题】智启未来:新质生产力引擎驱动下的智能制造行业革新报告合集PDF分享(附原数据表)
  • 邮件营销案例成功技巧:如何打动目标客户?
  • 18063 圈中的游戏
  • 探索极简计算的新边界:从Uxn虚拟机看未来编程生态
  • 儿童画画在线支付预约报名表单在线制作小程序源码系统 带完整的安装代码包以及搭建部署教程
  • 思迅商云8四级分类
  • 哪个牌子的护眼灯防蓝光效果好?五款市场上评价较高的护眼台灯
  • xtu oj 彩球
  • 自监督学习:引领机器学习的新革命
  • Java Mail腾讯企业邮箱或其他邮箱发送邮件失败bug记录