Skip to content 
Web Authorization Protocol                            A. Schwenkschuster
Internet-Draft                                             P. Kasselmann
Intended status: Standards Track                                   SPIRL
Expires: 4 June 2026                                             S. Rose
                                                                    NIST
                                                         1 December 2025

OAuth SPIFFE Client Authentication

draft-ietf-oauth-spiffe-client-auth-00

Abstract

本仕様は、OAuth 2.0におけるクライアント認証および認可付与のための Assertion Framework [RFC7521] と、OAuth 2.0におけるクライアント認証および認可付与のためのJWT Profile [RFC7523] をプロファイルし、OAuth 2.0においてSPIFFE Verifiable Identity Documents（SVID）をクライアント資格情報として利用できるようにします。SPIFFEの資格情報を持つOAuthクライアントが、client_secret を必要とせず、JWT-SVIDまたはX.509-SVIDを用いてOAuth authorization serverに認証できる方法を定義します。このアプローチは、SPIFFE対応のワークロードとOAuth authorization serverの間のシームレスな統合を可能にし、静的なclient_secretのような共有秘密を配布・管理する必要をなくすことで、セキュリティを強化します。

About This Document

この注記は、RFCとして公開する前に削除します。

本書のステータス情報は以下で確認できます。\ https://datatracker.ietf.org/doc/draft-ietf-oauth-spiffe-client-auth/

本書に関する議論は、Web Authorization Protocol Working Groupのメーリングリスト（mailto:oauth@ietf.org）で行われます。アーカイブは https://mailarchive.ietf.org/arch/browse/oauth/ にあります。\ 購読は https://www.ietf.org/mailman/listinfo/oauth/ から行います。

このドラフトのソースと課題トラッカーは以下にあります。\ https://github.com/arndt-s/oauth-spiffe-client-authentication

Status of This Memo

このInternet-Draftは、BCP 78およびBCP 79の規定に完全に準拠して提出されています。

Internet-Draftsは、Internet Engineering Task Force（IETF）の作業文書です。他のグループもInternet-Draftを配布する場合があることに留意してください。現行のInternet-Draftの一覧は https://datatracker.ietf.org/drafts/current/ にあります。

Internet-Draftsは最大6か月間有効なドラフト文書であり、随時更新、置換、または他の文書によって廃止される可能性があります。Internet-Draftsを参照資料として用いたり、「作業中のもの（work in progress）」以外として引用したりすることは不適切です。

このInternet-Draftは2026年6月4日に失効します。

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

本書は、IETF TrustのIETF文書に関する法的規定（https://trustee.ietf.org/license-info）に従います。これらの文書には、本書に関する権利および制限が記載されているため、注意深く確認してください。本書から抽出されたコードコンポーネントには、Trust Legal ProvisionsのSection 4.eに記載されたRevised BSD Licenseの本文を含めなければならず、またRevised BSD Licenseに記載のとおり無保証で提供されます。

Table of Contents

1. Introduction

従来のOAuthクライアント認証は、一般にclient_secret、またはprivate key JWT認証に依存していますが、いずれもOAuthクライアントへ秘密情報をアウトオブバンドで配布する必要があります。SPIFFE（Secure Production Identity Framework for Everyone）によってアイデンティティが管理される現代的なクラウドネイティブアーキテクチャでは、SVIDのような検証済みの識別子や資格情報が既に利用可能であるにもかかわらず、OAuthクライアント向けに追加の秘密情報を用意しなければならないという課題があります。

本仕様は、OAuth 2.0におけるクライアント認証のためのクライアント資格情報として、SPIFFE対応のワークロードがSPIFFE Verifiable Identity Documents（SVID）— すなわちX.509証明書またはJWTトークン — を利用できるようにするため、OAuth 2.0におけるクライアント認証および認可付与のための Assertion Framework [RFC7521] をプロファイルします。JWTトークンは、OAuth 2.0におけるクライアント認証および認可付与のためのJWT Profile [RFC7523] のプロファイル版を利用します。

このプロファイルは、OAuthクライアント認証にSPIFFEの資格情報を用いることに焦点を当てています。

クライアント認証のためのSPIFFEプロファイルは、SPIFFEベースのシステムとOAuthベースのシステムの間のシームレスな統合を可能にし、追加の資格情報管理を不要にしつつ、アプリケーションが両方のエコシステムを活用できるようにします。また、共有秘密ではなく暗号学的に検証可能な資格情報を活用することで、より安全な認証方式も実現します。

2. Conventions and Definitions

本書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174] に記載のとおり解釈されます。ただし、ここに示すように、すべて大文字で現れる場合に限ります。

2.1. Terminology

本仕様は、OAuth 2.0 [RFC6749]、OAuth 2.0向けの Assertion Framework [RFC7521]、そのJWTプロファイル [RFC7523]、およびSPIFFE仕様で定義された用語を使用します。特に、以下の用語が重要です。

  • Trust Domain: SPIFFEで定義されるとおり。Trust Domainは単一の信頼ルートを表します。あるTrust Domain内で発行されたすべてのSVIDは、そのTrust Domainの鍵によって検証可能です。
  • SPIFFE ID: spiffeスキームを用いてワークロードを一意かつ明確に識別する統一リソース識別子です。詳細は [SPIFFE_ID] を参照してください。
  • SVID: SPIFFE Verifiable Identity Document。本書は2種類のSVIDの利用を規定します。
    • X.509-SVID: URI SAN拡張にSPIFFE IDを含むX.509証明書です。詳細は [SPIFFE_X509] を参照してください。
    • JWT-SVID: sub claimにSPIFFE IDを含むJSON Web Token（JWT）です。詳細は [SPIFFE_JWT] を参照してください。
  • SPIFFE Bundle: Trust Domainによって発行されたSVIDを検証するための公開鍵と関連メタデータの集合です。
  • SPIFFE Bundle Endpoint: Trust Domain向けのSPIFFE bundleを提供するURLです。

3. OAuth Client Authentication Using SPIFFE

本節では、[RFC7521] で確立されたパターン（およびJWT-SVIDの場合は [RFC7523]）に従い、SPIFFEのアイデンティティ文書をOAuth 2.0のクライアント認証に利用する方法を説明します。

OAuth 2.0のクライアント認証は、token endpointへのリクエストを行う際に、クライアントがauthorization serverに対して自らを認証するために使用されます。SPIFFEを用いたクライアント認証では、クライアントは自身のSVID（JWT-SVIDまたはX.509-SVID）を提示して、アイデンティティを証明します。

3.1. Client Authentication with JWT-SVIDs

JWT-SVIDに基づく認証は、SPIFFEのJWT-SVID向けの特有の適用を加えつつ、OAuth 2.0向けのJWT Profileによるクライアント認証 [RFC7523] に自然に従います。[RFC7521] も引き続き有効です。

アサーション内容をJWT-SVIDとして識別するために、本仕様は [RFC6755] に従って、以下のクライアントアサーション型をOAuth URIとして定めます。

  • urn:ietf:params:oauth:client-assertion-type:jwt-spiffe

[RFC7523] に基づき、本仕様の文脈でクライアント認証を行うには、以下のリクエストパラメータが存在しなければなりません（MUST）。

  • client_assertion_type: MUST be set to urn:ietf:params:oauth:client-assertion-type:jwt-spiffe.
  • client_assertion: MUST be a single SPIFFE JWT-SVID.

JWT-SVIDによるクライアント認証リクエストを検証するために、authorization serverは以下を行わなければなりません（MUST）。

  1. JWTが適切な形式であり、必須claim（subにSPIFFE ID、aud、exp）をすべて含むことを検証する。
  2. JWTが失効していないことを検証する（exp claimを確認する）。
  3. aud claimが、唯一の値としてauthorization serverのissuer identifierのみを含むことを検証する。詳細は [I-D.draft-ietf-oauth-rfc7523bis] を参照。
  4. Section 5に従い、Trust Domainの署名鍵を用いてJWTの署名を検証する。
  5. sub claimのSPIFFE IDが、登録済みのクライアント識別子に一致する、または登録済みのクライアント識別子に関連付けられていることを検証する。

3.1.1. JWT-SVID example

以下の例は、SPIFFE JWT-SVIDを用いてクライアントを認証しつつ、OAuth 2.0 authorization serverのtoken endpointへauthorization_codeリクエストを行う例を示します。

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-spiffe&
client_assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjR2QzhhZ3ljSHU2cm5rRUVKWUFINlZ1Q2U0Sm9Ta1BWIiwidHlwIjoiSldUIn0.eyJhdWQiOlsiaHR0cHM6Ly9hcy5leGFtcGxlLmNvbS90b2tlbiJdLCJleHAiOjE3NDcxMjQ1NDMsImlhdCI6MTc0NzEyNDI0Mywic3ViIjoic3BpZmZlOi8vZXhhbXBsZS5vcmcvbXktb2F1dGgtY2xpZW50In0.Xlv5lW4cbxDsQk4l0paewG4nXOR7MxF_FMn_c27DX45Bxr2HUZf9a6Untfq5S47xpwbw495HBL6_1Lc6TMJxmw

明確化のため、SPIFFE-JWTのヘッダおよびボディをデコードしたものを以下に示します。

{
  "alg": "ES256",
  "kid": "4vC8agycHu6rnkEEJYAH6VuCe4JoSkPV",
  "typ": "JWT"
}

{
  "aud": [
    "https://as.example.com/token"
  ],
  "exp": 1747124543,
  "iat": 1747124243,
  "sub": "spiffe://example.org/my-oauth-client"
}

3.2. Client Authentication using X509-SVID

X.509-SVIDに基づく認証は、OAuth 2.0 Mutual-TLS Client Authentication [RFC8705] で定義されるmTLSを利用し、SPIFFEのX.509-SVID向けに特有の適用を加えます。

X.509-SVIDを用いて認証するには、クライアントはX.509-SVIDをクライアント証明書として用い、authorization serverとmTLS接続を確立します。authorization serverは、クライアント証明書をX.509-SVIDとして検証し、URI SANからSPIFFE IDを抽出します。サーバ証明書は、クライアントがシステムのトラストストアを用いて検証しなければならず（MUST）、SPIFFEのtrust bundleを用いてはなりません（NOT）。

リクエストには、クライアントのSPIFFE-IDを含む client_id パラメータを含めなければなりません（MUST）。これは、提示されたX509-SVIDのクライアント資格情報のURI SANと一致しなければなりません（MUST）。

サーバはクライアント証明書を以下の規則に従って検証します。

  1. Section 5に従い、信頼アンカーに対して標準的なX.509パス検証を実施する。
  2. 証明書が、有効なSPIFFE IDを持つURI SANをちょうど1つ含むことを検証する。
  3. 証明書がリーフ証明書であることを検証する（Basic Constraints拡張がCA=FALSEである）。
  4. 証明書のKey Usageにおいて digitalSignature ビットが設定されていることを検証する。
  5. URI SANのSPIFFE IDが、登録済みのクライアント識別子に一致する、または登録済みのクライアント識別子に関連付けられていることを検証する。

3.2.1. X509-SVID Example

以下のリクエストは、refresh token を用いて新しいaccess tokenを取得します。クライアントは spiffe://example.org/my-oauth-client であり、このリクエストをmTLS接続上で実行することで認証されます。

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&
refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&
client_id=spiffe://example.org/my-oauth-client

明確化のため、サーバへ提示されたX509-SVIDのクライアント証明書を openssl x509 -text によりデコードしたものを以下に示します。

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            dd:48:ec:d4:a4:c6:b2:ea:8e:9b:54:35:e8:30:65:7b
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=US, O=SPIFFE, serialNumber=6968729192859147614695638370388029008
        Validity
            Not Before: May 16 11:26:11 2025 GMT
            Not After : May 16 12:26:21 2025 GMT
        Subject: C=US, O=SPIRE
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:c2:0b:b6:8e:47:9a:20:ab:33:f1:a9:a5:77:97:
                    fa:a0:95:7d:2c:9f:e9:94:3d:e9:ed:e6:35:52:7f:
                    ff:82:34:74:20:97:5a:1b:4e:87:5f:32:3e:9d:da:
                    60:6a:05:8b:86:9d:0b:59:5f:67:be:93:3b:26:de:
                    ea:1e:18:98:96
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                D8:7A:2F:8B:E3:CF:08:83:EA:DD:5E:0A:59:33:6E:4C:E0:CC:6B:AD
            X509v3 Authority Key Identifier:
                C2:41:49:B0:ED:E0:94:7B:FA:7D:C2:F1:02:24:20:B9:1E:3D:56:FA
            X509v3 Subject Alternative Name:
                URI:spiffe://example.org/my-oauth-client
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:44:02:20:48:c3:5f:68:b2:c5:5d:96:c4:96:32:37:1f:af:
        b8:1c:1c:45:ad:41:26:dd:e2:92:b5:73:62:83:34:c6:16:2a:
        02:20:0f:48:02:8e:6b:1d:09:01:80:d8:85:2b:ca:25:c6:2c:
        9e:f2:27:c2:3c:e4:03:58:a8:47:21:f6:3c:5e:7a:c8

4. SPIFFE Trust Establishment and Client Registration

本仕様は、OAuth 2.0 Authorization Server とSPIFFE Trust Domainの間で、事前に信頼が確立されていることを要件とします。この作業はアウトオブバンドで行う必要があり、本仕様の範囲外です。ただし、鍵配布の仕組みは本仕様の範囲内であり、Section 5で説明します。

信頼確立と同様に、SPIFFEをクライアント認証として利用する前に、対応するOAuthクライアントを事前に確立しておく必要があります。これも範囲外です。実装者は例えば、[RFC7591] に従ったOAuth 2.0 dynamic client registration を利用する、またはアウトオブバンドで設定するといった選択ができます。

5. SPIFFE Key Distribution and Validation

本節では、authorization serverがX509またはJWT-SVIDの署名を検証する方法を説明します。SPIFFEネイティブな2つのアプローチを推奨します。

Trust bundleは一般に、Trust Domainと対応するbundleの取り違えを防ぐため、Trust Domain識別子でキー付けしなければなりません（MUST）。この2つのアプローチは併用できます。例えば次のとおりです。

  • Trust Domain "example.org": Workload API at unix:///var/secrets/spiffe/agent.sock
  • Trust Domain "production": SPIFFE Bundle Endpoint at https://example.com/auth/spiffe/bundle.json

5.1. SPIFFE Bundle Endpoint

SPIFFE Bundle Endpointは、[RFC7517] に従ったJSON Web Key Setを介して、X509-SVIDおよびJWT-SVIDの署名鍵をHTTPで公開します。

このendpointにおけるサーバ認証には2つの方式があります。本仕様の文脈では相互運用性のため、WebPKI方式を用いなければなりません（MUST）。これは実質的に、bundle endpointのサーバ証明書が、それへアクセスするauthorization serverから信頼されていることを意味します。詳細は [SPIFFE_FEDERATION] のSec 5.2.1を参照してください。

authorization serverは、bundle内で提供されるrefresh hintとperiodに従って、更新されたtrust bundleを取得するためにbundle endpointを定期的にポーリングすることが望ましいです（SHOULD）。詳細は [SPIFFE_FEDERATION] を参照してください。

SPIFFE bundle endpointはJWT-SVIDやX509-SVIDから導出できず、アウトオブバンドで手動設定しなければなりません（MUST）。Bundle endpointはTrust Domain識別子でキー付けしなければなりません（MUST）。

5.1.1. Example

以下の例は、Authorization ServerがTrust Domain example.org の鍵探索を行う方法を示します。重要なのは、example.org というTrust Domainと、SPIFFE Bundle Endpointの設置場所である example.com の違いです。これは、明示的な設定の重要性を強調するとともに、SPIFFE Bundle Endpointは明示的な設定なしにX509-SVIDから導出・発見できないという事実を裏付けます。

OAuth Authorization Server側のJSON形式の設定例:

{
  "example.org": {
    "spiffe_bundle_endpoint": {
      "url": "https://example.com/bundle.json"
    }
  }
}

Note difference between example.org and example.com

SPIFFE Bundle Endpointへのリクエスト／レスポンス例:

GET /bundle.json HTTP/1.1
Host: example.com

{
  "keys": [
    {
      "use": "x509-svid",
      "kty": "EC",
      "crv": "P-384",
      "x": "9XBzty8W_ex4Xr0RdzUBgie_okdaUTheSF0PQvVAaTsXaP1J7yv0Dhlaw45I7Cv9",
      "y": "HP21HOmMxIlZ0XeqsOl9sM5H57HBQWu0bINXfw4jdeHdB5vk1XyNyBQQxeUpSxhn",
      "x5c": [
        "MIIB2DCCAV6gAwIBAgIURJ20yIzal3ZT9NXkdwrsm0selwwwCgYIKoZIzj0EAwQwHjELMAkGA1UEBhMCVVMxDzANBgNVBAoMBlNQSUZGRTAeFw0yMzA1MTUwMjA1MDZaFw0yODA1MTMwMjA1MDZaMB4xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKDAZTUElGRkUwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAT1cHO3Lxb97HhevRF3NQGCJ7+iR1pROF5IXQ9C9UBpOxdo/UnvK/QOGVrDjkjsK/0c/bUc6YzEiVnRd6qw6X2wzkfnscFBa7Rsg1d/DiN14d0Hm+TVfI3IFBDF5SlLGGejXTBbMB0GA1UdDgQWBBSSiuNgxqqnz2r/jRcWsARqphwQ/zAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAZBgNVHREEEjAQhg5zcGlmZmU6Ly9sb2NhbDAKBggqhkjOPQQDBANoADBlAjEA54Q8hfhEd4qVycwbLNzOm/HQrp1n1+a2xc88iU036FMPancR1PLqgsODPfWyttdRAjAKIodUi4eYiMa9+I2rVbj8gOxJAFn0hLLEF3QDmXtGPpARs9qC+KbiklTu5Fpik2Q="
      ]
    },
    {
      "use": "jwt-svid",
      "kty": "EC",
      "kid": "6d02Vc2oU62mXVH5nlggHGLmfIhrlnNW",
      "crv": "P-256",
      "x": "S2V42XlFjNp30CFmOidbWQT9IpZHqJ8JuuJgDBvkdZA",
      "y": "vN0y5TK36VRxZo_E3Gc7S5c0jIRIaHZ53f2UiJ1NFto"
    }
  ],
  "spiffe_sequence": 10,
  "spiffe_refresh_hint": 300
}

JSON Web Keyにおける use パラメータは、その鍵が意図している資格情報の形式を示します。同じ use を持つ複数の鍵が存在してよいです。

上記レスポンスのX509-SVID署名証明書（.keys[0].x5c[0]）をテキスト形式で示します。

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            5c:4b:d5:2d:f9:c1:6e:78:2c:32:a6:bb:6c:73:f0:b8:f4:be:13:09
        Signature Algorithm: ecdsa-with-SHA512
        Issuer: C=US, O=SPIFFE
        Validity
            Not Before: May 16 11:23:19 2025 GMT
            Not After : May 15 11:23:19 2030 GMT
        Subject: C=US, O=SPIFFE
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:ef:3f:db:67:2b:e8:5c:a1:64:23:e7:f2:fd:f0:
                    3b:16:55:68:17:55:17:d4:bd:cd:6d:04:fd:cc:8f:
                    99:31:f7:8c:ac:b0:1e:31:60:18:45:32:8b:a1:17:
                    4b:2f:01:75:27:6c:3f:c3:a5:b9:da:56:fb:29:54:
                    63:cb:08:96:81:35:0e:96:04:03:40:fe:51:0d:26:
                    da:d5:99:6c:8f:c2:45:43:cb:2c:b4:8d:9b:68:78:
                    9f:c0:2d:68:36:b8:5e
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                8D:79:D2:26:5E:4C:83:30:40:C7:E9:1D:E1:35:12:F6:60:CF:0B:DB
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Subject Alternative Name:
                URI:spiffe://example.org
    Signature Algorithm: ecdsa-with-SHA512
    Signature Value:
        30:64:02:30:0a:e9:fd:d4:cd:99:52:90:cb:14:86:93:4e:f8:
        02:52:d6:17:12:9f:2e:65:99:0e:38:b6:b9:a6:fe:43:0f:60:
        30:04:87:ec:24:20:80:a4:75:ee:3c:ad:9d:a2:72:0d:02:30:
        55:93:0e:14:8c:47:47:3b:74:7c:a7:2a:2a:96:1d:a4:85:46:
        4f:3f:95:a4:c2:ab:3c:2e:04:b3:1b:cf:02:0f:33:fc:dd:dc:
        d5:2f:44:c8:2a:dc:ce:3f:c5:c6:89:d0

Arndt: BundleがX509-SVIDと一致していません。修正が必要です。

5.2. Alternative methods to avoid

以下の鍵配布メカニズムは代替案であり、相互運用性の観点から避けるべきです（SHOULD）。

5.2.1. SPIFFE Workload API

SPIFFE Workload APIは、ワークロードがTrust Bundleを取得できるようにします。これは、authorization serverがSPIFFE Trust Domainの一部であり、その中のワークロードとして扱われることを必要とします。SPIFFE Workload APIは、ワークロードがTrust Bundleの更新を能動的に取得するように構築されており、ポーリングを必要としないため、配布までの時間を短縮できます。ワークロードが属するTrust DomainのTrust Bundleに加え、SPIFFE Workload APIは、連携されたTrust DomainからのTrust Bundleも取得できます。

このアプローチがOAuth SPIFFE Client Authenticationに推奨されない（NOT RECOMMENDED）理由は複数あります。

  • OAuth Authorization ServerがSPIFFE Trust Domain内のワークロードである必要があり、デプロイのシナリオに対して大きな制約となります。
  • 連携されたTrust Domainのbundleは、どのように扱われるかが曖昧になり得ます。SPIFFE Workload APIを通じて配布される場合、信頼関係およびそれが確立される箇所が曖昧になり得ます。

5.2.2. Manual configuration

小規模で静的な環境では、authorization serverにSPIFFE bundleを手動で設定してもよい（MAY）。しかしこのアプローチは、設定、ローテーション、鍵素材の管理に人手が必要となるため、一般に推奨されません（NOT RECOMMENDED）。

5.2.3. Using the system trust store

X509-SVIDはシステムのトラストストアを用いて検証してはなりません（MUST NOT）。URI SANに含まれるSPIFFE IDは、より広いX.509エコシステムにおいて検証可能な属性であることは稀です。トラストアンカーとしてシステムのトラストストアを使用すると、その中の任意の認証局が、任意のSPIFFE IDに対して信頼されるX509-SVIDを発行できてしまいます。これに対し、SPIFFEネイティブの検証方法を用いれば、SPIFFE-IDの署名は対応するTrust Domainの署名鍵に制限されます。

5.2.4. Using the JWT-SVID iss claim

iss claimを持つJWT-SVIDは、OpenID Connect DiscoveryまたはOAuth 2.0 Authorization Server Metadataを通じて署名鍵を取得することで、技術的には検証できます。このアプローチはJWT-SVIDにのみ適用され、かつiss claimが存在する場合にのみ機能します。しかしiss claimの存在は保証されておらず、JWT-SVID仕様の一部でもありません。

適用可能性の範囲が狭いため、SPIFFE Bundle Endpointの代替として成立しません。相互運用性の懸念と合わせ、本アプローチは推奨されません（NOT RECOMMENDED）。

6. Implementation Status

// Note to RFC Editor: please remove this section, as well as the
// reference to RFC 7942, before publication.  This section records
// the status of known implementations of the protocol defined by this
// specification at the time of posting of this Internet-Draft, and is
// based on a proposal described in [RFC7942].  The description of
// implementations in this section is intended to assist the IETF in its
// decision processes in progressing drafts to RFCs.  Please note that
// the listing of any individual implementation here does not imply
// endorsement by the IETF.  Furthermore, no effort has been spent to
// verify the information presented here that was supplied by IETF
// contributors.  This is not intended as, and must not be construed to
// be, a catalog of available implementations or their features.
// Readers are advised to note that other implementations may exist.

本節は、本仕様で定義されるプロトコルの既知の実装状況を、Internet-Draft投稿時点で記録するものであり、[RFC7942] に記載された提案に基づきます。本節の実装記述は、IETFがドラフトをRFCへ進めるか判断する際に役立てることを意図しています。ここに特定の実装を掲載しても、IETFがそれを推奨していることを意味しません。また、IETF寄稿者から提供された情報の検証には労力を割いていません。これは利用可能な実装や機能のカタログとして意図されたものではなく、そのように解釈してはなりません。読者は、他にも実装が存在し得ることに留意してください。

RFC 7942によれば、「これにより、レビューアやワーキンググループは、動作するコードの恩恵を受けている文書に対して適切な考慮を割り当てられる。動作するコードは、価値ある実験やフィードバックの証拠となり、実装されたプロトコルをより成熟させた可能性がある。ワーキンググループがこの情報をどのように用いるかは、各ワーキンググループ次第である」。

Keycloak

  • Organization: Red Hat / CNCF
  • Maturity: preview
  • Coverage: SPIFFE Trust Bundle Endpointを用いたJWT-SVIDによるクライアント認証
  • Contact: Keycloak community & maintainers\ https://www.keycloak.org/community

7. Security Considerations

JWT-SVIDを用いたクライアント認証は、[RFC6749] および [RFC7521] に記載のセキュリティ上の考慮事項と同じ考慮事項を持ちます。

X509-SVIDを用いたクライアント認証は、[RFC8705] に記載のセキュリティ上の考慮事項と同じ考慮事項を持ちます。Section 3.2の検証規則は、適切なX509-SVIDを提示しなかったクライアントに対してOAuth2 tokenが発行される（または誤って発行される）ことから保護します。

上記Section 5.2で述べた問題には、authorization serverが誤ったトラストストアを設定してクライアントSVIDを検証してしまう脅威が含まれます。これにより、攻撃者が、トラストストア内の誤設定された信頼アンカーのいずれかで検証可能な証明書を入手できた場合、攻撃者に対して誤ってtokenが発行される可能性があります。

8. IANA Considerations

本書は、Oauth URIレジストリに新しいエントリを追加することを要求します。レジストリは以下にあります。

  • https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#uri\ （参照: https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#uri）

登録手続きは [RFC6755] で定義されます。本書は、以下のエントリをレジストリへ追加することを要求します。

  • URN: urn:ietf:params:oauth:client-assertion-type:jwt-spiffe
  • Common Name: SPIFFE JWT-SVID Profile for OAuth 2.0 Client Authentication
  • Change Controller: IETF
  • Reference: This Document

9. Normative References

[I-D.draft-ietf-oauth-rfc7523bis]

Jones, M. B., Campbell, B., Mortimore, C., and F. Skokan,\ "Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants",\ Work in Progress, Internet-Draft, draft-ietf-oauth-rfc7523bis-03, 7 October 2025,\ https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rfc7523bis-03.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119,\ DOI 10.17487/RFC2119, March 1997,\ https://www.rfc-editor.org/rfc/rfc2119.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749,\ DOI 10.17487/RFC6749, October 2012,\ https://www.rfc-editor.org/rfc/rfc6749.

[RFC6755]

Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755,\ DOI 10.17487/RFC6755, October 2012,\ https://www.rfc-editor.org/rfc/rfc6755.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517,\ DOI 10.17487/RFC7517, May 2015,\ https://www.rfc-editor.org/rfc/rfc7517.

[RFC7521]

Campbell, B., Mortimore, C., Jones, M., and Y. Goland,\ "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521,\ DOI 10.17487/RFC7521, May 2015,\ https://www.rfc-editor.org/rfc/rfc7521.

[RFC7523]

Jones, M., Campbell, B., and C. Mortimore,\ "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523,\ DOI 10.17487/RFC7523, May 2015,\ https://www.rfc-editor.org/rfc/rfc7523.

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt,\ "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591,\ DOI 10.17487/RFC7591, July 2015,\ https://www.rfc-editor.org/rfc/rfc7591.

[RFC7942]

Sheffer, Y. and A. Farrel,\ "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942,\ DOI 10.17487/RFC7942, July 2016,\ https://www.rfc-editor.org/rfc/rfc7942.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174,\ DOI 10.17487/RFC8174, May 2017,\ https://www.rfc-editor.org/rfc/rfc8174.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt,\ "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705,\ DOI 10.17487/RFC8705, February 2020,\ https://www.rfc-editor.org/rfc/rfc8705.

[SPIFFE_BUNDLE]

"SPIFFE Bundle", n.d.,\ https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md#4-spiffe-bundle-format.

[SPIFFE_FEDERATION]

"SPIFFE Federation", n.d.,\ https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Federation.md.

[SPIFFE_ID]

"SPIFFE-ID", n.d.,\ https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md.

[SPIFFE_JWT]

"JWT-SVID", n.d.,\ https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md.

[SPIFFE_X509]

"X509-SVID", n.d.,\ https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md.

Appendix A. Document History

// RFC Editor: please remove before publication.

A.1. draft-ietf-oauth-spiffe-client-auth-00

  • OAuth working groupへの採択を反映するため、文書名を更新。

A.2. draft-schwenkschuster-oauth-spiffe-client-auth-01

  • クライアント認証への焦点がより明確になるよう、Introductionを言い換え。
  • 実装に関する節を追加。
  • ワーキンググループ文書として採択されたRFC7523bisから、audience制約を追加。
  • セキュリティおよびIANA Considerationsの節を追加。
  • Scott Roseを共同著者として追加。

A.3. draft-schwenkschuster-oauth-spiffe-client-auth-00

  • 初版

Acknowledgments

TODO: 謝辞を記載する。

Authors' Addresses

Arndt Schwenkschuster\ SPIRL\ Email: arndts.ietf@gmail.com

Pieter Kasselmann\ SPIRL\ Email: pieter@spirl.com

Scott Rose\ NIST\ Email: scott.rose@nist.gov