Skip to content

MS_OIDCClientAuth

nishi_74322014 edited this page Sep 1, 2026 · 1 revision

OpenID Connect - クライアント認証

概要

Final を参照して記述。

  • OAuth 2.0 では
    「クライアントは 1 回のリクエストにおいて二つ以上の認証方式を利用してはならない (MUST NOT).」
    と言われている。

  • Registration の際、
    Token エンドポイントにアクセスする際のクライアント認証方法を登録可能。

詳細

認証方法

以下の名称は、Discovery で使用される値で、なにかのパラメタ値では無い。

補足(一覧): 以下の 5 つは、
クライアント自身が誰であるかをどう示すかの選択肢である。
下に行くほど、秘密の値をネットワークに流さない方向に強くなる。

方式 何を送るか 秘密の値が回線に乗るか
none 何も送らない
client_secret_basic client_id + client_secret(Authorization ヘッダ) 乗る
client_secret_post client_id + client_secret(ボディ) 乗る
client_secret_jwt client_secret を鍵にした MAC 署名付き JWT 乗らない
private_key_jwt 秘密鍵で署名した JWT 乗らない

FAPI のような高セキュリティ プロファイルでは、
private_key_jwt(または mTLS)が要求される。

none

以下のケースで Token エンドポイントでの認証を行わない場合。

  • Implicit Flow
  • Public クライアント
  • およびその他の何らかの認証手段を用いる場合

client_secret_basic(既定値)

  • OAuth 2.0 の慣例(ただし、仕様に明記はない)
  • Client Credential(client_idclient_secret)を HTTP Basic 認証スキーマで送信する。

client_secret_post

client_secret_jwt

private_key_jwt

JWTの共通項

JWT Bearer Token Flow的

JWT bearer token authorization グラント種別

  • 「Self-Issued Assertion」の
  • 「クライアント認証あり(サーバ信頼セキュリティ モデル)」

のユースケースに相当する。

クレーム

こちらも、上記の「JWT Bearer Token Flow」のユースケース的。

# 要件 クレーム
1 REQUIRED iss client_id
2 sub
3 aud Token Endpoint URL
4 jti JWTクレームセット参照
5 exp
6 OPTIONAL iat

補足(isssub も client_id): 表の 1・2 のとおり、
この JWT はクライアントが自分自身について発行するものなので、
発行者(iss)と主体(sub)がどちらも client_id になる。
audToken エンドポイントの URL にするのは、
別のエンドポイント宛の JWT を使い回されないようにするためで、
jtiexp は同じ JWT の再利用(リプレイ)を防ぐために使う。

移行メモ(表の体裁): 元ページの表はセル結合(|~|)で
縦方向の繰り返しを表していたが、GitHub の Markdown は
セル結合に対応していないため に置き換えた。

送信方法

こちらも、上記の「JWT Bearer Token Flow」のユースケース的。

  • client_assertion パラメタ
    前述の、署名暗号化された JWTJWS, JWE)を使用する。

  • client_assertion_type パラメタ:
    urn:ietf:params:oauth:client-assertion-type:jwt-bearer

参考

本 Wiki 内


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

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally