マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

  • Mutual TLS(MTLS) :
    OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
  • Mutual TLS というと、単に「TLS 通信時にクライアント側も証明書を提示する」ことを意味する。
  • FAPI の文脈では、記名式切符の作成と使用。
    • クライアント証明書による OAuth クライアント認証
    • クライアント証明書に紐付くトークンに関する処理
  • 別称「Certificate Binding」で、以下を選択的に使用できる。

※ このページは、ドラフト 12 を参考にして作成。

方法

X.509証明書のクライアント証明書を使用する。

  • TLSハンドシェイクにより秘密鍵の所有を検証する。
  • クライアント証明書の入れ替えは自由に行うことが出来る。
  • 以下のケースで処理方式が異なってくる。

公開鍵基盤(PKI)

  • TLS 通信で用いられた公開鍵基盤(PKI)のクライアント証明書を用いる方式
    • 証明書チェーンと、
    • 事前登録したサブジェクト識別名(DN)を使用する。
      (その場合のメタデータは、tls_client_auth_subject_dn)

自己署名証明書

  • TLS 通信で用いられた自己署名のクライアント証明書を用いる方式
    • 証明書チェーンを検証しない
    • 当該自己署名証明書と、
    • 事前登録した公開鍵(jwks_uri等)を使用する。
      (このメタデータは定義されていない)

シーケンス

バインディング

  • Token EndpointでMutual TLSクライアント認証する。
  • X.509証明書のHashによりClientとAccess Tokenを結び付ける。

ベリファイ

  • Resource EndPoint?でMutual TLSクライアント認証する。
  • Resource Serverは、X.509証明書のHashと、Access Tokenの結び付けを検証する。

方式のメリット・デメリット

メリット

  • Client自体は殆ど何も変えなくて良い。
  • 対応しなければならないのはServer側。

デメリット

解らない。

  • Client自身のリスク管理には、その情報が必要なので、
    同じリソースURIは、「持参人切符」は取り扱ってはならない。
  • 異なるAuthorization Schemeではなく、
    Bearerスキーマをそのまま使うのは、
    英国のOpen Bankingでの採用のし易さに配慮した結果。

対象のEndPoint?

Authorization Server

Authorization Serverの下記のエンドポイントにクライアント認証の追加メカニズムを提供。

Resource Server

任意のエンドポイント

詳細

クライアント証明書によるクライアント認証

  • client_idパラメタが必須
    クライアント証明書の内容とは独立してClientを識別するため。
  • クライアント証明書をClient Credentialsとして使用して、
    client_idをバインドする2つの異なった方法がある。
  • なお、Clientの登録方法に依存しない。
    • 動的に登録
    • 静的に構成
    • 別の方法で確立

tls_client_auth

tls_client_auth_subject_dn

  • クライアント証明書の予想されるサブジェクト識別名の文字列表現。

self_signed_tls_client_auth

(メタデータの規定は無し)

  • jwks_uriJwk Setから、
    x5cパラメタの最初の証明書の公開鍵
    (RSA = "n" and "e", EC = "x" and "y")を取得。

送信者制限付きAccess Token

  • 送信者制限には、x5t#S256(SHA-256による証明書フィンガープリント)を使用する。
  • x5t#S256は以下の様に規定されるので通常、thumbprintの文字列をそのまま扱えばイイ。
    base64url-encoded [RFC4648] SHA-256 [SHS] hash
    (a.k.a. thumbprint, fingerprint or digest)
    of the DER encoding of the X.509 certificate [RFC5280].

バインディング

ClientがTokenエンドポイントへの接続でクライアント証明書を使用すると、
Authorization Serverは発行されたAccess Tokenをクライアント証明書にバインドできる。

  • Access Tokenに証明書ハッシュを埋め込む
    • JWTに、cnf > x5t#S256 メンバとして埋め込む。
    • 以下は、x5t#S256を含むJWTペイロードの例。
          {
            "iss": "https://server.example.com",
            "sub": "ty.webb@example.com",
            "exp": 1493726400,
            "nbf": 1493722800,
            "cnf":{
              "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
            }
          }
  • Introspectionエンドポイント
    Introspectionエンドポイントから以下のような、x5t#S256を含むメタデータを返す。
        HTTP/1.1 200 OK
        Content-Type: application/json
    
        {
          "active": true,
          "iss": "https://server.example.com",
          "sub": "ty.webb@example.com",
          "exp": 1493726400,
          "nbf": 1493722800,
          "cnf":{
            "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
          }
        }

ベリファイ

Clientは、Resourceリクエストに、Tokenリクエストで使用したクライアント認証を使用する必要がある。
証明書が一致しない場合は、HTTP 401と "invalid_token"で拒否が必須。)

メタデータ

OpenID Connect - Discovery

  • mutual_tls_sender_constrained_access_tokens
    • 本仕様のサポートを示すbool値。
    • オプション。default値は "false"。

OpenID Connect - Dynamic Client Registration

  • mutual_tls_sender_constrained_access_tokens
    • 本仕様を使用する意図を示すbool値。
    • オプション。default値は "false"。

考慮事項

実装に関する

Server

  • Authorization Server
  • 他のクライアント認証をサポートする場合、
    (MTLS)クライアント認証をオプションにする。
  • クライアント認証を必要としない他のエンドポイントを、
    他のホスト名でホストすることを考慮してもよい。
  • Resource Server
    Resource Serverは、クライアントの証明書のチェーンを検証する必要はないので、
    証明書チェーンを検証しないようにTLSスタックを構成する必要がある。

Access Token

クライアント認証と"送信者制限付きAccess Token"は、互いに独立して使用できる。

  • クライアント認証なしの"送信者制限付きAccess Token"
    • クライアント認証なしで、"送信者制限付きAccess Token"のみ使用できる。
    • Tokenリクエストで、証明書チェーンを検証しないようにTLSスタックを構成する必要がある。
    • Resourceリクエストで、クライアント認証書とAccess Tokenから取得した証明書フィンガープリントを比較する。

※ 互いに独立して使用できるというコトは、

  • tls_client_auth
  • self_signed_tls_client_auth

をクライアント認証のみで使用することもできる?

Implicit Flowはサポートされない。

  • TokenエンドポイントへリクエストしないImplicit Flowはサポートできない。
  • 逆に、Hybrid Flowのサポートも必要だが、Tokenエンドポイントで処理しさえすればよい。

セキュリティに関する

TLS

  • バージョン
    • 主流なので、TLS 1.2 [RFC5246]を引用。
    • 最近発表された、TLS 1.3 [RFC8446]を推奨。
  • 考慮事項
    BCP 195, RFC 7525: Recommendations for Secure Use of TLS and DTLS
  • ネットワーク仲介者
    • ロードバランサ、リバースプロキシなどで、TLSが中断されても良い。
    • この場合、クライアント証明書メタデータを受け渡す方法は仕様の範囲外。

X.509証明書と証明書チェーンの解析と検証

  • X.509証明書と証明書チェーンの解析と検証は複雑
  • 実装ミスによって以前にセキュリティの脆弱性が露呈していた。
  • 十分にテストされたX.509ライブラリを使用するべきで、
    独自のX.509証明書検証手順を書かないこと。

証明書スプーフィング

  • 同じサブジェクト識別名(DN)を持つ証明書を使用してクライアントを偽装しようとする可能性がある。
  • 従って、証明書発行ポリシーがセキュリティ要件を満たしている限られた数のCAだけを信頼アンカーとして受け入れるべき。

OAuth 2.0 Token Bindingとの関連

類似点

OAuth 2.0 Token Binding

「Tokenを、Client上の非対称キー・ペアにバインドする」処理方式は、

"送信者制限付きAccess Token"に対する

  • デザイン
  • モチベーション

に対して、幾つかの類似点がある。

デザイン

  • Authorization Serverが発行したAccess Tokenを、
    Client上の非対称キー・ペアにバインドする。
    • Client上で生成される非対称キー・ペアを使用し、
    • 秘密鍵保持の証明(Proof of Possession、POP)を行う。

モチベーション

規制要件によって動機付けられたOAuth対応の金融取引で、

  • 証明書の作成、配布、および管理の難しさの多くを回避し、
  • より広範な導入と展開を見込む可能性がある。

相違点

OAuth 2.0 Token Binding

まだ、新しく、現在の開発プラットフォームとツールでは、比較的少数のサポートしかない。

OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens

  • しばらく前からあり、現在の開発プラットフォームとツールで広くサポートされている。
  • こちらは、OAuth 2.0 Token Bindingより、迅速なソリューション提供を目指している。

参考

OAuth 2.0 Token Binding

ASP.NET+クライアント証明書


Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-03-01 (金) 09:47:37 (49d)