Apereo CAS OpenID Connect 推送授权请求（PAR）实战指南：原理、配置与源码剖析

后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载PARPushed Authorization Request推送授权请求是 OIDC/OAuth 2.0 生态中用于提升授权请求机密性与完整性的关键机制。本文以 Apereo CAS 的 OpenID Connect 协议实现为背景完整讲解 PAR 的工作原理、oidcPushAuthorize端点的交互流程、cas.authn.oidc.par配置项的语义并结合仓库源码与测试用例剖析 CAS 内部如何将 PAR 请求建模为票据Ticket、如何控制其有效期与使用次数帮助读者掌握在 CAS 中启用、验证与排查 PAR 的完整实战能力。PAR 是什么把授权请求“推”给授权服务器在传统的 OIDC 授权码流程中客户端通过浏览器user-agent以 URL 查询参数的形式把整个授权请求发送到授权服务器的授权端点authorization endpoint。这种方式有两个先天弱点授权请求的全部参数暴露在浏览器地址栏、历史记录与各类代理日志中机密性差攻击者可以截获、篡改或重放授权请求完整性得不到保障。PARRFC 草案 Pushed Authorization Requests改变了这一交互模型客户端通过一条直连direct request的 POST 请求把 OIDC 授权请求的完整负载“推”送给 CAS即授权服务器。CAS 处理后会返回一个request_uri该 URI 只是授权请求数据的一个引用reference。随后客户端把request_uri交给浏览器由 user-agent 在后续对授权端点的调用中携带该引用即可完成授权流程。这种“推后引用”的设计带来了多方面的安全收益机密性与完整性授权请求的敏感参数不再经过浏览器而是经由客户端与 CAS 之间的直接通道传输天然具备更好的保密与防篡改能力更高级的安全诉求需要更高安全等级、尤其是需要密码学确认的不可否认性cryptographically confirmed non-repudiation的客户端可以将 PAR 与基于 JWT 的 request object 结合使用双保险叠加更早的客户端身份确认PAR 允许 CAS 在任何用户交互发生之前就完成对客户端的认证。授权过程中对客户端身份的信心增强使得 CAS 可以在流程的更早阶段就拒绝非法请求从而有效防止客户端伪造spoofing、请求篡改或滥用。CAS 对 PAR 的支持位于 OIDC 模块中核心实现落在 support/cas-server-support-oidc-core-api 与 support/cas-server-support-oidc 两个子模块。典型的 PAR 交互流程一次典型的 PAR 交换流程如下客户端直接向 CAS 的oidcPushAuthorize端点发送POST请求将授权请求整体“推”给 CASCAS 验证客户端身份与请求参数如client_id、redirect_uri、response_type等校验通过后CAS 生成一个request_uri返回给客户端并同时给出该引用对应的有效期响应形如{ expires_in: 30, request_uri: OPAR-1-... }客户端随后把request_uri作为参数提交回 CAS 的授权端点authorization endpointCAS 根据该引用恢复restore并继续resume此前被推送的授权请求进而走完登录、同意与回调流程。上述 JSON 响应中request_uri即票据 ID其前缀OPAR-来自 OidcPushedAuthorizationRequest 的PREFIX常量expires_in则来自该票据过期策略的timeToLive。端点与控制器GET 被拒绝POST 才合法PAR 端点在 CAS 中的实现类是 OidcPushedAuthorizeEndpointController它继承自 OIDC 的授权端点控制器并覆写了两个映射GetMapping(/**/ OidcConstants.PUSHED_AUTHORIZE_URL)明确返回405 Method Not Allowed。PAR 只接受 POST用 GET 访问会被直接拒绝PostMapping(/**/ OidcConstants.PUSHED_AUTHORIZE_URL)处理真正的推送请求。在处理前会先通过IssuerService.validateIssuer校验 issuer失败则返回invalid_request错误校验通过后委托给父类OidcAuthorizeEndpointController完成后续的参数解析与验证。从端点路径的注册方式/**/前缀可以看出PAR 端点的完整访问路径由 CAS 的上下文路径默认/cas OIDC 端点前缀/oidc 端点名拼接而成即形如POST /cas/oidc/oidcPushAuthorize这一点与仓库中的测试用例互相印证OidcPushedAuthorizeEndpointControllerTests 中分别以get(/cas/oidc/ OidcConstants.PUSHED_AUTHORIZE_URL)与post(/cas/oidc/ OidcConstants.PUSHED_AUTHORIZE_URL)发起请求断言前者返回isMethodNotAllowed()后者在携带合法参数时返回isCreated()且响应 JSON 中同时存在request_uri与expires_in两个字段。核心配置cas.authn.oidc.parPAR 相关的全部配置项都挂在cas.authn.oidc.par命名空间下其底层配置模型是 OidcPushedAuthorizationProperties它被标注为依赖模块cas-server-support-oidc。具体参数如下配置项默认值说明cas.authn.oidc.par.number-of-uses1控制同一个request_uriPAR 票据在 CAS 服务器内可以被使用的次数。默认 1 次用后即失效可有效防重放cas.authn.oidc.par.max-time-to-live-in-secondsPT30SPAR 票据的硬性存活时间TTL超过该时长即被强制过期。取值使用 ISO-8601 时长格式如PT30S表示 30 秒也可写为秒数形式cas.authn.oidc.par.storage-nameoidcPushedAuthzRequestsCacheCAS 在底层票据注册表ticket registry中为存放 PAR 而创建/使用的存储对象名称示例配置application.properties# 允许一个 request_uri 最多被使用 1 次默认 cas.authn.oidc.par.number-of-uses1 # PAR 票据最长存活 30 秒默认 cas.authn.oidc.par.max-time-to-live-in-secondsPT30S # PAR 在票据注册表中的存储名称默认 cas.authn.oidc.par.storage-nameoidcPushedAuthzRequestsCache配置如何转化为过期策略从源码角度看这些配置项并非摆设。PAR 票据的过期策略由 OidcPushedAuthorizationRequestExpirationPolicyBuilder 构建其核心逻辑为读取casProperties.getAuthn().getOidc().getPar()即上述三个配置用Beans.newDuration(par.getMaxTimeToLiveInSeconds())把 ISO-8601 时长解析为秒数构造OidcPushedAuthorizationRequestExpirationPolicy(numberOfUses, timeToLive)该类继承 CAS 的MultiTimeUseOrTimeoutExpirationPolicy。也就是说PAR 票据遵循的是**“次数 超时”双约束**无论哪个条件先触发使用次数耗尽或 TTL 到期票据都会失效。这解释了为什么默认配置下expires_in为 30——它正是max-time-to-live-in-secondsPT30S的体现而number-of-uses1则保证了每次 push 生成的request_uri只能被消费一次从机制上杜绝了重放攻击。票据模型PAR 请求如何在 CAS 内部流转PAR 推送成功后CAS 会把整个授权请求保存为一张票据。票据的默认实现是 OidcDefaultPushedAuthorizationRequest它扩展了 CAS 的AbstractTicket并持有authentication推送时携带的认证信息service目标服务registeredService已注册的 OAuth/OIDC 服务定义authorizationRequest被推送的原始授权请求内容。票据的创建与恢复分别由接口 OidcPushedAuthorizationRequestFactory 的create与toAccessTokenRequest两个方法负责其默认实现为 OidcDefaultPushedAuthorizationRequestFactory。创建票据的调用链可以从响应构建器 OidcPushedAuthorizationRequestUriResponseBuilder 中看得很清楚通过TicketFactory取得OidcPushedAuthorizationRequestFactory调用factory.create(holder)生成票据将票据addTicket写入TicketRegistry票据注册表读取uri.getExpirationPolicy().getTimeToLive()作为expires_in读取uri.getId()作为request_uri拼装成响应参数返回给客户端。而恢复请求的路径同样在该类中当用户代理携带request_uri访问授权端点时CAS 先从TicketRegistry取出对应票据并检查是否过期过期则删除未过期则将其更新同时用票据中保存的认证信息合并 TGT 的认证属性重建AccessTokenRequestContext从而让后续授权流程“无缝续上”此前被推送的请求。强制启用 PARrequire-pushed-authorization-requests除了默认开放的 PAR 能力外CAS 还支持在发现配置discovery层面强制要求所有授权请求都必须走 PAR。该开关对应的配置项为cas.authn.oidc.discovery.require-pushed-authorization-requeststrue该配置位于 OIDC 的发现端点设置对应 OidcDiscoveryProperties中。启用后CAS 会要求客户端遵循pushed_authorization_request_endpoint的指引先执行 push 再发起授权未携带有效request_uri的普通授权请求会被拦截。这一点在测试中也有直接体现OidcAuthorizeEndpointControllerTests 中专门划分了PushedAuthorizationRequests测试组并设置了该属性OidcHandlerInterceptorAdapterTests 同样使用该属性验证拦截器行为OidcPushedAuthorizeEndpointControllerTests 也基于该属性验证 PAR 端点的成功/失败路径。从 OidcServerDiscoverySettings 的源码可以看到CAS 会把pushed_authorization_request_endpoint计算并公布到 OIDC 发现文档中其值正是issuer拼接OidcConstants.PUSHED_AUTHORIZE_URL客户端可以据此动态发现 PAR 端点地址。测试用例如何验证 PAR 行为仓库为 PAR 提供了完整的测试覆盖是理解其行为边界的绝佳参照OidcPushedAuthorizeEndpointControllerTestsverifyGetOperationFailsGET 访问 PAR 端点 →405 Method Not AllowedverifyPostWithoutRequiredParamsPOST 但缺少必要参数 →403 ForbiddenverifyPostOperation携带client_id、client_secret、redirect_uri、response_typecode的合法 POST →201 Created且响应同时含request_uri与expires_inverifyPostOperationInvalidRedirectUriredirect_uri与注册服务不匹配 →403 Forbidden。票据与过期策略侧OidcPushedAuthorizationRequestExpirationPolicyBuilderTests验证 TTL 与使用次数如何生成过期策略OidcPushedAuthorizationRequestValidatorTests验证 request_uri 引用的票据是否有效OidcDefaultPushedAuthorizationRequestFactoryTests 与 OidcPushedAuthorizationRequestUriResponseBuilderTests验证票据创建与响应构建。这些测试从端到端MockMvc 层到单元票据/策略层两级覆盖也印证了前面所述的全部行为事实。实战建议与注意事项按安全等级分层启用默认情况下 PAR 能力即可用若部署环境对授权请求机密性要求苛刻如高风险企业单点登录场景可开启cas.authn.oidc.discovery.require-pushed-authorization-requeststrue强制全量走 PAR并配合 JWT request object 实现不可否认性。合理调优 TTL 与次数request_uri的生命周期应短于用户完成一次登录所需的合理时间。默认PT30S偏短若客户端与浏览器跳转链路较慢导致请求经常过期可适当放宽number-of-uses保持默认1即可这是防重放的关键防线不建议调大。关注票据注册表的存储位置PAR 票据写入的是 CAS 的 TicketRegistrystorage-nameoidcPushedAuthzRequestsCache因此在高可用集群中PAR 票据的行为受票据注册表实现Redis、Hazelcast、JPA 等的一致性语义影响。选用分布式票据注册表时应确保 PAR 票据能跨节点被授权端点读取。调试入口排查 PAR 问题时可关注OidcPushedAuthorizationRequestUriResponseBuilder中输出的日志如 “Generated pushed authorization URI code: [...]” 与 “Pushed authorization request verification successful for client [...]”结合审计日志该响应构建器带有Audit注解对应OAUTH2_AUTHORIZATION_RESPONSE审计动作定位是哪一步失败。总结PAR 是 CAS OIDC 实现中把“授权请求安全送达”前置到客户端直连通道的关键机制通过oidcPushAuthorize端点接收 POST 推送、返回短期有效的request_uri引用、以票据形式在 TicketRegistry 中保存请求并用“次数 TTL”双约束控制票据生命周期。配合cas.authn.oidc.par三个配置项与require-pushed-authorization-requests强制开关部署者可以按需在机密性、防篡改与防重放之间取得平衡。本文所引用的控制器、响应构建器、票据实现与过期策略构建器均可直接在仓库源码与测试中找到对应证据是进一步深入阅读的良好起点。赞分享后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载相关推荐Apereo CAS OpenID Connect Scope Approval作用域授权确认机制与配置指南Apereo CAS OpenID Connect Scope Approval作用域授权确认机制与配置指南 导读 Scope Approval作用域授权确后端认证鉴权单点登录Apereo CAS OpenID Connect JWT Bearer 授权模式JWT Authorization Grant接入指南Apereo CAS OpenID Connect JWT Bearer 授权模式JWT Authorization Grant接入指南 JWT Beare后端认证鉴权单点登录Apereo CAS 的 OpenID Connect Pairwise 标识符sub配置与实现原理Apereo CAS 的 OpenID Connect Pairwise 标识符sub配置与实现原理 Pairwise成对subject type 是后端认证鉴权单点登录创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考