1.2. sender-constraining 访问令牌


1.2.1. 演示 Possession 的证明证明(DPoP)

RFC9449 描述了一种将访问令牌绑定到当前客户端的轮询证明(DPoP)机制,防止访问令牌丢失和重播。

单个页面应用程序(SPA)公共客户端生成 DPoP 证明令牌,并使用它们获取和提交访问令牌,这些访问令牌以加密方式绑定到 DPoP 证明。

在 Quarkus 中启用 DPoP 支持需要一个属性。

例如:

quarkus.oidc.auth-server-url=${your_oidc_provider_url}
quarkus.oidc.token.authorization-scheme=dpop 1
1
要求访问令牌使用 HTTP 授权 DPoP 方案值来提供。

接受此类令牌后,Quarkus 将经过完整的 DPoP 令牌验证过程

以后可能会提供对自定义 DPoP 非供应商的支持。

1.2.2. 双向 TLS 令牌绑定

RFC8705 描述了将访问令牌绑定到 Mutual TLS (mTLS)客户端身份验证证书的机制。它要求客户端证书的 SHA256 thumbprint 与 JWT 令牌或令牌内省确认 x5t#S256 证书 thumbprint 匹配。

例如,请参阅 RFC8705 的 Token Introspection 部分的 JWT 证书 Thumbprint 确认方法和确认方法

MTLS 令牌绑定支持 密钥概念的所有者,可用于确认当前访问令牌已发布到提供此令牌的当前验证客户端。

当使用 mTLS 和 OIDC bearer 验证机制时,您可以在将 Quarkus 端点和 Quarkus OIDC 配置为需要使用 mTLS 后,强制访问令牌必须是与单个属性绑定的证书。

例如:

quarkus.oidc.auth-server-url=${your_oidc_provider_url}
quarkus.oidc.token.binding.certificate=true 1
quarkus.oidc.tls.tls-configuration-name=oidc-client-tls 2

quarkus.tls.oidc-client-tls.key-store.p12.path=target/certificates/oidc-client-keystore.p12 3
quarkus.tls.oidc-client-tls.key-store.p12.password=password
quarkus.tls.oidc-client-tls.trust-store.p12.path=target/certificates/oidc-client-truststore.p12
quarkus.tls.oidc-client-tls.trust-store.p12.password=password

quarkus.http.tls-configuration-name=oidc-server-mtls 4
quarkus.tls.oidc-server-mtls.key-store.p12.path=target/certificates/oidc-keystore.p12
quarkus.tls.oidc-server-mtls.key-store.p12.password=password
quarkus.tls.oidc-server-mtls.trust-store.p12.path=target/certificates/oidc-server-truststore.p12
quarkus.tls.oidc-server-mtls.trust-store.p12.password=password
1
要求 bearer 访问令牌必须绑定到客户端证书。
2 3
Quarkus OIDC 的 TLS registry 配置可以通过 MTLS 与 OIDC 供应商通信
4
需要外部客户端通过 MTLS 向 Quarkus 端点进行身份验证的 TLS registry 配置

以上配置足以要求 OIDC bearer 令牌绑定到客户端证书。

接下来,如果您需要访问 mTLS 和 OIDC bearer 安全身份,请考虑使用 quarkus.http.auth.inclusive=true 启用 Inclusive 身份验证

现在,您可以访问 MTLS 和 OIDC 安全身份,如下所示:

package io.quarkus.it.oidc;

import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;

import org.eclipse.microprofile.jwt.JsonWebToken;
import io.quarkus.security.Authenticated;
import io.quarkus.security.credential.CertificateCredential;
import io.quarkus.security.identity.SecurityIdentity;

@Path("/service")
@Authenticated
public class OidcMtlsEndpoint {

    @Inject
    SecurityIdentity mtlsIdentity; 1

    @Inject
    JsonWebToken oidcAccessToken; 2

    @GET
    public String getIdentities() {
        var cred = identity.getCredential(CertificateCredential.class).getCertificate();
        return "Identities: " + cred.getSubjectX500Principal().getName().split(",")[0]
                + ", " + accessToken.getName();
    }
}
1
当使用 mTLS 并启用了包含的身份验证时,SecurityIdentity 始终代表主要的 mTLS 身份验证。
2
OIDC 安全身份也可用,因为启用包含的身份验证需要所有注册的机制来生成安全身份。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat, Inc.