Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

1.2. 送信者制限アクセストークン

1.2.1. Demonstrating Proof of Possession (DPoP)
リンクのコピー

RFC9449 では、アクセストークンを現在のクライアントに暗号的にバインドし、アクセストークンの紛失やリプレイを防ぐための Demonstrating Proof of Possession (DPoP) メカニズムを説明しています。

Single Page Application (SPA) パブリッククライアントは、DPoP 証明トークンを生成し、それを使用して DPoP 証明に暗号的にバインドされたアクセストークンを取得および送信します。

Quarkus で DPoP サポートを有効にするには、1 つのプロパティーが必要です。

以下に例を示します。 

quarkus.oidc.auth-server-url=${your_oidc_provider_url}
quarkus.oidc.token.authorization-scheme=dpop
1
Copy to Clipboard Toggle word wrap
1
アクセストークンは HTTP Authorization DPoP スキーム値を使用して提供される必要があります。

このようなトークンを受け入れた後、Quarkus は完全な DPoP トークン検証プロセス を実行します。

将来的にはカスタム DPoP nonce プロバイダーのサポートが提供される予定です。

1.2.2. 相互 TLS トークンバインディング
リンクのコピー

RFC8705 では、アクセストークンを Mutual TLS (mTLS) クライアント認証証明書にバインドするメカニズムを説明しています。クライアント証明書の SHA256 サムプリントが JWT トークンまたはトークンイントロスペクション確認 x5t#S256 証明書サムプリントと一致する必要があります。

たとえば、RFC8705 の JWT Certificate Thumbprint Confirmation Method および Confirmation Method for Token Introspection セクションを参照してください。

MTLS トークンバインディングは holder of key の概念をサポートしており、現在のアクセストークンがこのトークンを提示する現在の認証済みクライアントに発行されたことを確認するために使用できます。

mTLS と OIDC ベアラー認証メカニズムの両方を使用する場合、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
Copy to Clipboard Toggle word wrap
1
ベアラーアクセストークンをクライアント証明書にバインドする必要があることを必須にします。
2 3
Quarkus OIDC の TLS レジストリー設定により、MTLS 経由で OIDC プロバイダーと通信できるようになります。
4
外部クライアントが MTLS 経由での Quarkus エンドポイントの認証を必須にする TLS レジストリー設定

上記の設定を使用すると、OIDC ベアラートークンをクライアント証明書にバインドすることが必須にできます。

次に、mTLS と OIDC ベアラーセキュリティーアイデンティティーの両方にアクセスする必要がある場合は、quarkus.http.auth.inclusive=true を使用して 包括的認証 を有効にすることを検討してください。

次のようにして、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();
    }
}
Copy to Clipboard Toggle word wrap
1
mTLS が使用され、統合認証が有効になっている場合、SecurityIdentity は常にプライマリー mTLS 認証を表します。
2
統合認証を有効にするには、登録されているすべてのメカニズムでセキュリティーアイデンティティーを生成する必要があるため、OIDC セキュリティーアイデンティティーも利用できます。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat