拓冰网站定制 
后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载导读授权码Authorization Code是 OAuth 2.0 中最经典的授权类型专为用户与界面交互的场景设计用户先在 CAS 登录页输入凭据随后获得一个一次性授权码再将该授权码兑换为访问令牌Access Token。本文以 Apereo CAS 实际实现的/oauth2.0/authorize与/oauth2.0/accessToken两个端点为主线完整讲解授权码流程的参数、响应与调用方式并结合源码剖析 CAS 如何实现 PKCERFC 7636扩展来保护公共客户端public client的授权码不被窃取利用。读完本文你将能够基于 CAS 正确接入授权码流程并为其配置plain或S256方式的 PKCE 校验。授权码流程为 UI 交互而生授权码类型的设计目标是用户在场的交互式场景。与客户端凭据Client Credentials等纯机器对机器流程不同授权码流程把用户认证与令牌颁发拆成两步客户端引导用户浏览器跳转到 CAS 的授权端点用户完成登录并授权CAS 将授权码通过回调地址redirect_uri返回给客户端客户端在后端使用授权码向令牌端点换取访问令牌授权码一次性有效且生命周期极短。这种两步式设计保证了访问令牌不会暴露在浏览器地址栏中即使授权码在传输途中被截获攻击者也无法直接拿到访问令牌若配合 PKCE截获的授权码更完全不可用。授权码流程的两个核心端点原文档给出了授权码流程在两个端点上的完整参数契约下表完整保留并补充说明端点请求参数响应/oauth2.0/authorizeresponse_typecodeclient_idIDredirect_uriCALLBACKOAuth 授权码以CALLBACKURL 的参数形式返回。/oauth2.0/accessTokengrant_typeauthorization_codeclient_idIDclient_secretSECRETcodeCODEredirect_uriCALLBACK返回访问令牌Access Token。第一步发起授权请求客户端将用户浏览器重定向到 CAS 的授权端点https://cas.example.org/cas/oauth2.0/authorize?response_typecodeclient_idCLIENT_IDredirect_uriCALLBACK各参数含义response_typecode声明本次使用授权码响应类型这是触发授权码流程的关键标记client_id客户端在 CAS 中注册的标识redirect_uri授权完成后 CAS 携带授权码跳转回的回调地址必须与客户端注册时登记的地址一致。CAS 在收到请求后会执行 OAuth20AuthorizeEndpointController 的处理器逻辑解析client_id、redirect_uri、response_type、scope、state等参数校验注册服务访问策略检查当前会话是否已认证必要时呈现同意确认视图最终在用户认证通过后将授权码以回调 URL 参数的形式返回https://client.example.org/callback?codeOC-xxxx-xxxxCAS 的 OAuth 授权码票据以OC为前缀且为一次性、短生命周期票据这一点可以从 OAuth20Code 接口的注释与定义中得到印证。第二步用授权码兑换访问令牌客户端拿到授权码后在后端直接向令牌端点发起请求绝不能放在浏览器端完成POST /cas/oauth2.0/accessToken grant_typeauthorization_codeclient_idCLIENT_IDclient_secretSECRETcodeCODEredirect_uriCALLBACK令牌端点在 CAS 中由 OAuth20AccessTokenEndpointController 处理同时暴露accessToken与token两个路径。请求会先经过一组AccessTokenGrantRequestValidator校验器确认授权类型与参数合法再通过审计执行器提取出AccessTokenRequestContext最后交给响应编码器生成令牌响应。成功后响应体以 JSON 形式返回访问令牌及其元信息如access_token、token_type、expires_in等。需要特别说明令牌交换请求中同时要求client_id与client_secret这是对机密客户端confidential client的强身份校验而公共客户端无法安全保管 secret 的浏览器/移动端应用则应当启用下文介绍的 PKCE 机制。Proof Key Code ExchangePKCE扩展解决什么问题PKCEProof Key for Code Exchange读作 pixie规范为 RFC 7636为公共客户端提供了一种缓解授权码被截获威胁的技术手段。其思路是客户端在发起授权请求前先自行生成一个密钥code verifier并基于它派生出挑战值code challenge随授权请求一并发出等到用授权码兑换令牌时再把最初的密钥code verifier提交上来。这样一来即使授权码在传输中被拦截由于攻击者不知道最初的密钥令牌请求依然无法成功。授权端点的 PKCE 参数原文档说明授权端点/oauth2.0/authorize支持以下参数激活 PKCE参数说明code_challenge使用下方方法生成的代码挑战值。code_challenge_methodplain、S256。该参数可选缺省时默认按plain处理。在源码层面这两个参数由 OAuth20AuthorizeEndpointController 从请求中解析并写入待构建的AccessTokenRequestContext随后在生成授权码票据时一并持久化。其中code_challenge_method的取值并非任意字符串而是会先经过配置的受支持方法列表过滤见下文配置与默认值再统一转为大写存储。令牌端点的 PKCE 参数令牌端点/oauth2.0/accessToken支持以下参数完成 PKCE 校验参数说明code_verifier客户端在发起授权请求之前最初生成的原始代码验证值。参数名常量code_challenge、code_challenge_method、code_verifier在 OAuth20Constants 中统一定义OAuth 与 OIDC 两个协议模块共用。plain 与 S256 的校验逻辑原文档明确给出了两种方法的差异这里完整继承并补充实现细节若方法是plainCAS 只需检查提交的code_verifier是否与先前存储的code_challenge字符串一致若方法是S256CAS 需要使用与客户端最初相同的变换方法处理提交的code_verifier即计算该 verifier 的 SHA256 哈希再进行 base64-url 编码最后与存储的code_challenge比对只要 verifier 与期望值匹配CAS 便按正常流程继续颁发访问令牌并给出相应响应。该逻辑在 CAS 中由 OAuth20ProofKeyCodeExchangeAuthenticator 的calculateCodeVerifierHash方法实现private static String calculateCodeVerifierHash(final String method, final String codeVerifier) { if (plain.equalsIgnoreCase(method)) { return codeVerifier; } if (S256.equalsIgnoreCase(method)) { val sha256 DigestUtils.rawDigestSha256(codeVerifier); return EncodingUtils.encodeUrlSafeBase64(sha256); } throw new CredentialsException(Code verification method is unrecognized: method); }可以看到plain分支直接返回原值S256分支先对 verifier 做 SHA256 摘要再做 URL 安全的 Base64 编码——这与 RFC 7636 规定的S256变换BASE64URL(SHA256(verifier))完全一致。源码视角PKCE 校验的完整链路结合 OAuth20ProofKeyCodeExchangeAuthenticatorPKCE 在 CAS 中的校验流程可以还原为以下步骤判定适用性canAuthenticate方法检查请求中是否同时携带code_verifier与code两个参数只有二者齐备才走 PKCE 认证分支客户端凭据校验先通过OAuth20ClientSecretValidator校验client_secret公共客户端可配置空 secret测试用例verifyPKCEEmptySecret验证了空 secret 场景可以正常放行取回授权码票据以请求中的code为键从 Ticket Registry 中取出OAuth20Code票据若票据不存在或已过期则直接拒绝还原挑战值从票据上读取当初存储的codeChallengeMethod缺省视为plain据此对提交的code_verifier做相同变换比对判定将变换结果与票据上的codeChallenge做忽略大小写的比较不一致则抛出CredentialsException拒绝令牌请求一致则放行进入正常令牌颁发流程。授权码票据上之所以能够保存这些信息是因为 OAuth20Code 接口定义了getCodeChallenge()与getCodeChallengeMethod()这两个字段在授权请求阶段由授权端点控制器写入在令牌交换阶段被 PKCE 认证器读取校验形成完整的闭环。测试用例验证仓库中的集成测试 OAuth20AccessTokenEndpointControllerTests 为上述行为提供了可复现的证据verifyPKCECodeVerifier使用plain方法、提交与 challenge 一致的 verifier令牌请求返回 200 并携带访问令牌verifyPKCEInvalidCodeVerifier提交错误的 verifier如invalidcode令牌请求返回 401 且错误码为invalid_grantverifyPKCEEmptySecret注册服务 secret 为空公共客户端形态时配合正确的 verifier 依然能成功换取令牌verifyPKCEWrongSecretsecret 错误时请求被拒绝401。这些用例从正反两面确认了PKCE 校验失败直接导致令牌请求失败且校验与 client secret 校验是相互独立的两道关卡。配置与默认值PKCE 方法支持范围通过配置项控制。在 CAS 配置模型 OidcDiscoveryProperties 中codeChallengeMethodsSupported的默认值为[plain, S256]对应配置文件写法为cas.authn.oidc.discovery.code-challenge-methods-supportedplain,S256授权端点控制器正是用该配置列表对请求中的code_challenge_method进行白名单过滤不在列表中的方法会被置空从而退回默认行为。也就是说CAS 开箱即用同时支持plain与S256两种 PKCE 方法无需额外配置即可启用 PKCE。注册服务与安全实践要点启用授权码流程与 PKCE 时客户端还需在 CAS 中注册为 OAuth 服务配置client_id、client_secret、授权类型AUTHORIZATION_CODE与回调地址白名单完整步骤参见 OAuth-Authentication 与 OAuth-Authentication-Clients 文档。在此基础上建议公共客户端务必启用 PKCE浏览器应用、原生 App 无法安全保管 secret应生成高熵的 verifier如 32 字节以上随机数并优先使用S256方法——它在传输中不暴露原始 verifier安全性优于plain授权码请求携带state参数用于防 CSRF 与回跳伪造CAS 授权端点同样解析并回传state严格核对redirect_uri回调地址必须与注册值完全一致避免开放重定向被利用令牌交换在后端完成client_secret与code_verifier绝不应出现在浏览器侧代码中。小结Apereo CAS 的 OAuth 2.0 授权码流程以/oauth2.0/authorize与/oauth2.0/accessToken两个端点承载了完整的认证授权 令牌兑换链路并原生实现了 RFC 7636 的 PKCE 扩展默认同时支持plain与S256。从授权请求阶段写入code_challenge/code_challenge_method到令牌交换阶段由OAuth20ProofKeyCodeExchangeAuthenticator还原并比对 verifierCAS 将 PKCE 校验完整融入授权码票据的生命周期之中。对于构建面向浏览器的单页应用或原生移动端登录基于 CAS 的授权码 S256PKCE 组合是既标准又安全的落地选择。赞分享后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载相关推荐Apereo CAS OAuth 2.0 Refresh Token 授权流程Refresh Token Grant完全解析Apereo CAS OAuth 2.0 Refresh Token 授权流程Refresh Token Grant完全解析 本文围绕 Apereo CAS后端认证鉴权单点登录Apereo CAS OAuth 隐式授权流Implicit Flow / Token Response Type实战指南Apereo CAS OAuth 隐式授权流Implicit Flow / Token Response Type实战指南 本指南以 Apereo CAS后端认证鉴权单点登录Salt Player 怎么装怎么用开源免费无广告的安卓本地音乐播放器上手指南Salt Player 怎么装怎么用开源免费无广告的安卓本地音乐播放器上手指南 手机自带的播放器太素商业 App 又满屏广告Salt Player 是一款上一篇OHIF Viewers 3.8 到 3.9 迁移指南分割架构、状态管理与 UI 全面升级实战下一篇NodeGui 桌面应用开发使用 QTableWidget 构建基于单元格的表格视图创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apereo CAS OAuth 2.0 授权码流程（Authorization Code）与 PKCE 扩展实战指南
后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载导读授权码Authorization Code是 OAuth 2.0 中最经典的授权类型专为用户与界面交互的场景设计用户先在 CAS 登录页输入凭据随后获得一个一次性授权码再将该授权码兑换为访问令牌Access Token。本文以 Apereo CAS 实际实现的/oauth2.0/authorize与/oauth2.0/accessToken两个端点为主线完整讲解授权码流程的参数、响应与调用方式并结合源码剖析 CAS 如何实现 PKCERFC 7636扩展来保护公共客户端public client的授权码不被窃取利用。读完本文你将能够基于 CAS 正确接入授权码流程并为其配置plain或S256方式的 PKCE 校验。授权码流程为 UI 交互而生授权码类型的设计目标是用户在场的交互式场景。与客户端凭据Client Credentials等纯机器对机器流程不同授权码流程把用户认证与令牌颁发拆成两步客户端引导用户浏览器跳转到 CAS 的授权端点用户完成登录并授权CAS 将授权码通过回调地址redirect_uri返回给客户端客户端在后端使用授权码向令牌端点换取访问令牌授权码一次性有效且生命周期极短。这种两步式设计保证了访问令牌不会暴露在浏览器地址栏中即使授权码在传输途中被截获攻击者也无法直接拿到访问令牌若配合 PKCE截获的授权码更完全不可用。授权码流程的两个核心端点原文档给出了授权码流程在两个端点上的完整参数契约下表完整保留并补充说明端点请求参数响应/oauth2.0/authorizeresponse_typecodeclient_idIDredirect_uriCALLBACKOAuth 授权码以CALLBACKURL 的参数形式返回。/oauth2.0/accessTokengrant_typeauthorization_codeclient_idIDclient_secretSECRETcodeCODEredirect_uriCALLBACK返回访问令牌Access Token。第一步发起授权请求客户端将用户浏览器重定向到 CAS 的授权端点https://cas.example.org/cas/oauth2.0/authorize?response_typecodeclient_idCLIENT_IDredirect_uriCALLBACK各参数含义response_typecode声明本次使用授权码响应类型这是触发授权码流程的关键标记client_id客户端在 CAS 中注册的标识redirect_uri授权完成后 CAS 携带授权码跳转回的回调地址必须与客户端注册时登记的地址一致。CAS 在收到请求后会执行 OAuth20AuthorizeEndpointController 的处理器逻辑解析client_id、redirect_uri、response_type、scope、state等参数校验注册服务访问策略检查当前会话是否已认证必要时呈现同意确认视图最终在用户认证通过后将授权码以回调 URL 参数的形式返回https://client.example.org/callback?codeOC-xxxx-xxxxCAS 的 OAuth 授权码票据以OC为前缀且为一次性、短生命周期票据这一点可以从 OAuth20Code 接口的注释与定义中得到印证。第二步用授权码兑换访问令牌客户端拿到授权码后在后端直接向令牌端点发起请求绝不能放在浏览器端完成POST /cas/oauth2.0/accessToken grant_typeauthorization_codeclient_idCLIENT_IDclient_secretSECRETcodeCODEredirect_uriCALLBACK令牌端点在 CAS 中由 OAuth20AccessTokenEndpointController 处理同时暴露accessToken与token两个路径。请求会先经过一组AccessTokenGrantRequestValidator校验器确认授权类型与参数合法再通过审计执行器提取出AccessTokenRequestContext最后交给响应编码器生成令牌响应。成功后响应体以 JSON 形式返回访问令牌及其元信息如access_token、token_type、expires_in等。需要特别说明令牌交换请求中同时要求client_id与client_secret这是对机密客户端confidential client的强身份校验而公共客户端无法安全保管 secret 的浏览器/移动端应用则应当启用下文介绍的 PKCE 机制。Proof Key Code ExchangePKCE扩展解决什么问题PKCEProof Key for Code Exchange读作 pixie规范为 RFC 7636为公共客户端提供了一种缓解授权码被截获威胁的技术手段。其思路是客户端在发起授权请求前先自行生成一个密钥code verifier并基于它派生出挑战值code challenge随授权请求一并发出等到用授权码兑换令牌时再把最初的密钥code verifier提交上来。这样一来即使授权码在传输中被拦截由于攻击者不知道最初的密钥令牌请求依然无法成功。授权端点的 PKCE 参数原文档说明授权端点/oauth2.0/authorize支持以下参数激活 PKCE参数说明code_challenge使用下方方法生成的代码挑战值。code_challenge_methodplain、S256。该参数可选缺省时默认按plain处理。在源码层面这两个参数由 OAuth20AuthorizeEndpointController 从请求中解析并写入待构建的AccessTokenRequestContext随后在生成授权码票据时一并持久化。其中code_challenge_method的取值并非任意字符串而是会先经过配置的受支持方法列表过滤见下文配置与默认值再统一转为大写存储。令牌端点的 PKCE 参数令牌端点/oauth2.0/accessToken支持以下参数完成 PKCE 校验参数说明code_verifier客户端在发起授权请求之前最初生成的原始代码验证值。参数名常量code_challenge、code_challenge_method、code_verifier在 OAuth20Constants 中统一定义OAuth 与 OIDC 两个协议模块共用。plain 与 S256 的校验逻辑原文档明确给出了两种方法的差异这里完整继承并补充实现细节若方法是plainCAS 只需检查提交的code_verifier是否与先前存储的code_challenge字符串一致若方法是S256CAS 需要使用与客户端最初相同的变换方法处理提交的code_verifier即计算该 verifier 的 SHA256 哈希再进行 base64-url 编码最后与存储的code_challenge比对只要 verifier 与期望值匹配CAS 便按正常流程继续颁发访问令牌并给出相应响应。该逻辑在 CAS 中由 OAuth20ProofKeyCodeExchangeAuthenticator 的calculateCodeVerifierHash方法实现private static String calculateCodeVerifierHash(final String method, final String codeVerifier) { if (plain.equalsIgnoreCase(method)) { return codeVerifier; } if (S256.equalsIgnoreCase(method)) { val sha256 DigestUtils.rawDigestSha256(codeVerifier); return EncodingUtils.encodeUrlSafeBase64(sha256); } throw new CredentialsException(Code verification method is unrecognized: method); }可以看到plain分支直接返回原值S256分支先对 verifier 做 SHA256 摘要再做 URL 安全的 Base64 编码——这与 RFC 7636 规定的S256变换BASE64URL(SHA256(verifier))完全一致。源码视角PKCE 校验的完整链路结合 OAuth20ProofKeyCodeExchangeAuthenticatorPKCE 在 CAS 中的校验流程可以还原为以下步骤判定适用性canAuthenticate方法检查请求中是否同时携带code_verifier与code两个参数只有二者齐备才走 PKCE 认证分支客户端凭据校验先通过OAuth20ClientSecretValidator校验client_secret公共客户端可配置空 secret测试用例verifyPKCEEmptySecret验证了空 secret 场景可以正常放行取回授权码票据以请求中的code为键从 Ticket Registry 中取出OAuth20Code票据若票据不存在或已过期则直接拒绝还原挑战值从票据上读取当初存储的codeChallengeMethod缺省视为plain据此对提交的code_verifier做相同变换比对判定将变换结果与票据上的codeChallenge做忽略大小写的比较不一致则抛出CredentialsException拒绝令牌请求一致则放行进入正常令牌颁发流程。授权码票据上之所以能够保存这些信息是因为 OAuth20Code 接口定义了getCodeChallenge()与getCodeChallengeMethod()这两个字段在授权请求阶段由授权端点控制器写入在令牌交换阶段被 PKCE 认证器读取校验形成完整的闭环。测试用例验证仓库中的集成测试 OAuth20AccessTokenEndpointControllerTests 为上述行为提供了可复现的证据verifyPKCECodeVerifier使用plain方法、提交与 challenge 一致的 verifier令牌请求返回 200 并携带访问令牌verifyPKCEInvalidCodeVerifier提交错误的 verifier如invalidcode令牌请求返回 401 且错误码为invalid_grantverifyPKCEEmptySecret注册服务 secret 为空公共客户端形态时配合正确的 verifier 依然能成功换取令牌verifyPKCEWrongSecretsecret 错误时请求被拒绝401。这些用例从正反两面确认了PKCE 校验失败直接导致令牌请求失败且校验与 client secret 校验是相互独立的两道关卡。配置与默认值PKCE 方法支持范围通过配置项控制。在 CAS 配置模型 OidcDiscoveryProperties 中codeChallengeMethodsSupported的默认值为[plain, S256]对应配置文件写法为cas.authn.oidc.discovery.code-challenge-methods-supportedplain,S256授权端点控制器正是用该配置列表对请求中的code_challenge_method进行白名单过滤不在列表中的方法会被置空从而退回默认行为。也就是说CAS 开箱即用同时支持plain与S256两种 PKCE 方法无需额外配置即可启用 PKCE。注册服务与安全实践要点启用授权码流程与 PKCE 时客户端还需在 CAS 中注册为 OAuth 服务配置client_id、client_secret、授权类型AUTHORIZATION_CODE与回调地址白名单完整步骤参见 OAuth-Authentication 与 OAuth-Authentication-Clients 文档。在此基础上建议公共客户端务必启用 PKCE浏览器应用、原生 App 无法安全保管 secret应生成高熵的 verifier如 32 字节以上随机数并优先使用S256方法——它在传输中不暴露原始 verifier安全性优于plain授权码请求携带state参数用于防 CSRF 与回跳伪造CAS 授权端点同样解析并回传state严格核对redirect_uri回调地址必须与注册值完全一致避免开放重定向被利用令牌交换在后端完成client_secret与code_verifier绝不应出现在浏览器侧代码中。小结Apereo CAS 的 OAuth 2.0 授权码流程以/oauth2.0/authorize与/oauth2.0/accessToken两个端点承载了完整的认证授权 令牌兑换链路并原生实现了 RFC 7636 的 PKCE 扩展默认同时支持plain与S256。从授权请求阶段写入code_challenge/code_challenge_method到令牌交换阶段由OAuth20ProofKeyCodeExchangeAuthenticator还原并比对 verifierCAS 将 PKCE 校验完整融入授权码票据的生命周期之中。对于构建面向浏览器的单页应用或原生移动端登录基于 CAS 的授权码 S256PKCE 组合是既标准又安全的落地选择。赞分享后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载相关推荐Apereo CAS OAuth 2.0 Refresh Token 授权流程Refresh Token Grant完全解析Apereo CAS OAuth 2.0 Refresh Token 授权流程Refresh Token Grant完全解析 本文围绕 Apereo CAS后端认证鉴权单点登录Apereo CAS OAuth 隐式授权流Implicit Flow / Token Response Type实战指南Apereo CAS OAuth 隐式授权流Implicit Flow / Token Response Type实战指南 本指南以 Apereo CAS后端认证鉴权单点登录Salt Player 怎么装怎么用开源免费无广告的安卓本地音乐播放器上手指南Salt Player 怎么装怎么用开源免费无广告的安卓本地音乐播放器上手指南 手机自带的播放器太素商业 App 又满屏广告Salt Player 是一款上一篇OHIF Viewers 3.8 到 3.9 迁移指南分割架构、状态管理与 UI 全面升级实战下一篇NodeGui 桌面应用开发使用 QTableWidget 构建基于单元格的表格视图创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考