idp-server API (1.0.0)

Download OpenAPI specification:Download

OAuth 2.0 / OpenID Connect 1.0 に準拠したエンドポイント仕様

CIBAフロー

OpenID Connect Client Initiated Backchannel Authentication (CIBA) フローは、リダイレクトやユーザーエージェントを介さずに認証を行う、非同期かつデバイス分離型のOpenID Connect認証フローです。

ユーザーがRelying Party（RP）と操作する端末（Consumption Device）と、認証や同意を行う端末（Authentication Device）を分離して設計されており、 RPがユーザーの識別子を既に知っている場合に、OPからアクセストークンやIDトークンを非同期で取得できます。

📘 仕様詳細（OpenID公式）:
OpenID Connect Client Initiated Backchannel Authentication Core 1.0

バックチャンネル認証リクエスト

CIBA（Client-Initiated Backchannel Authentication）フローのバックチャンネル認証リクエストエンドポイント。 OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 に準拠。

このエンドポイントはクライアント認証を必要とします。以下のクライアント認証方式に対応しています（Client Authentication）：

client_secret_basic：AuthorizationヘッダにBasic認証形式で client_id / client_secret を送信します（デフォルト）。
client_secret_post：client_id と client_secret をフォームパラメータとしてリクエストボディに含めます。
client_secret_jwt：client_secret を共通鍵として署名した JWT を client_assertion として送信します。
private_key_jwt：登録済みの公開鍵に対応する秘密鍵で署名した JWT を client_assertion として送信します。
tls_client_auth（mTLS）：クライアント証明書を使って双方向TLS認証を行います。サーバーは証明書のサブジェクトなどでクライアントを識別します。
self_signed_tls_client_auth（自己署名TLS）: 自己署名のクライアント証明書を用いたTLS認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。
attest_jwt_client_auth：Client Attestation JWT と Client Attestation PoP JWT をOAuth-Client-Attestation / OAuth-Client-Attestation-PoP ヘッダで送信します（draft-ietf-oauth-attestation-based-client-auth）。ボディにもヘッダにもシークレットを載せないため、配布物にシークレットを埋め込めないネイティブアプリで使います。

JWT認証（client_secret_jwt / private_key_jwt）では、以下のクレームを含むJWTを生成し、次のパラメータを使用して送信してください：

client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion: 署名済みJWT

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

header Parameters

Authorization	string Basic認証ヘッダー（client_secret_basic認証方式用）。 `Basic base64(client_id:client_secret)` 形式で送信します。
OAuth-Client-Attestation	string <jwt> Client Attestation JWT（`attest_jwt_client_auth` 用）。 Client Attester が発行した JWT で、`cnf.jwk` にクライアントインスタンスの公開鍵を持ちます。 `OAuth-Client-Attestation-PoP` と必ず対で送信します（片方だけのリクエストは拒否されます）。 `typ` は `oauth-client-attestation+jwt`。
OAuth-Client-Attestation-PoP	string <jwt> Client Attestation PoP JWT（`attest_jwt_client_auth` 用）。 `OAuth-Client-Attestation` の `cnf.jwk` に対応する秘密鍵で署名し、そのインスタンスが鍵を保持していることを示します。`typ` は `oauth-client-attestation-pop+jwt`。テナントが `client_attestation_challenge_required` を有効にしている場合、 `challenge` クレームにチャレンジエンドポイントで得た値が必要です。

Request Body schema: application/x-www-form-urlencoded
required

client_id

string

クライアントの識別子。クライアント認証方式が client_secret_basicの場合は省略可能。

client_secret

string

クライアントシークレット。クライアント認証方式が client_secret_postの場合は必須。

scope

required

string

必須。openid を含める必要がある。例：openid profile email

login_hint

string

ユーザーを識別するヒント。IDやメールアドレスなど ※login_hintまたはid_token_hintの指定が必要

login_hint

login_hint には複数の拡張形式をサポートし、柔軟なユーザー特定が可能です。

フォーマット	意味	例
`sub:<subject>`	内部ユーザーIDで直接識別	`sub:abc123`
`ex-sub:<subject>,idp:<id-provider>`	外部IdPのサブジェクトで識別	`ex-sub:ex-idp123,idp:ex-idp`
`device:<deviceId>,idp:<id-provider>`	認証デバイスで識別	`device:device123,idp:ex-idp`
`email:<email>,idp:<id-provider>`	メールアドレスによる識別	`email:foo@example.com,idp:idp-server`
`phone:<number>,idp:<id-provider>`	電話番号による識別	`phone:09012345678,idp:idp-server`

idp-provider のデフォルト値は idp-server。

id_token_hint

string

過去の ID Token を用いたユーザー識別 ※login_hintまたはid_token_hintの指定が必要

binding_message

string <= 20 characters

ユーザー端末に表示される文言（最大20文字）

requested_expiry

integer

auth_req_id の有効期限（秒）

request_context

string

認証時の追加情報

acr_values

string

要求する認証強度（ACR値）

user_code

string

ユーザー認証デバイスでの認証リクエスト送信を許可するためのコード。悪意のある認証リクエストからユーザーを保護するためのオプショナルパラメータ。

Array of objects (AuthorizationDetails)

RFC 9396 で定義された authorization detail オブジェクトの配列。各オブジェクトは特定のアクセス要求を表します。また、typeに応じて拡張プロパティを含めることができます（e.g., 'geolocation', 'currency'）。

Responses

Response samples

Content type

application/json

{"auth_req_id": "string",
"expires_in": 0,
"interval": 0
}

認可コードフロー

OpenID Connect 認可コードフローは、OAuth 2.0 を基盤とした認証フローであり、 Relying Party（クライアント）がエンドユーザーのアイデンティティを安全かつ確実に取得するための標準的な手法です。

このフローは 認証コード（authorization code） を通じて、アクセストークンや ID トークンを取得する構成となっており、クライアントと認可サーバーの間にユーザーのブラウザ（User Agent）を介在させることで、セキュアな認可と認証を両立します。

🔐 OpenID Connect の特長：

OAuth 2.0 にアイデンティティレイヤーを追加
id_token を用いてエンドユーザーを識別
userinfo エンドポイントによるプロフィール情報の取得

🔑 典型的なユースケース：

Webアプリケーションのログイン
SPA（Single Page Application）やモバイルアプリのサーバー認証連携

📘 関連仕様：

Pushed Authorization Request (PAR)

RFC 9126 に準拠した Pushed Authorization Request エンドポイント。

認可リクエストのパラメータを事前に送信し、request_uri を取得します。この request_uri を使用して通常の認可エンドポイントにリクエストを送信できます。

セキュリティ上の利点：

認可パラメータの URL 経由での漏洩を防止
クライアント認証と認可リクエストを分離
大きなリクエストパラメータ（RAR等）への対応

クライアント認証

このエンドポイントは クライアント認証が必須 です。以下の認証方法をサポートしています：

client_secret_basic：AuthorizationヘッダにBasic認証形式で client_id / client_secret を送信します（デフォルト）。
client_secret_post：client_id と client_secret をフォームパラメータとしてリクエストボディに含めます。
client_secret_jwt：client_secret を共通鍵として署名した JWT を client_assertion として送信します。
private_key_jwt：登録済みの公開鍵に対応する秘密鍵で署名した JWT を client_assertion として送信します。
tls_client_auth（mTLS）：クライアント証明書を使って双方向TLS認証を行います。サーバーは証明書のサブジェクトなどでクライアントを識別します。
self_signed_tls_client_auth（自己署名TLS）: 自己署名のクライアント証明書を用いたTLS認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。
attest_jwt_client_auth：Client Attestation JWT と Client Attestation PoP JWT をOAuth-Client-Attestation / OAuth-Client-Attestation-PoP ヘッダで送信します（draft-ietf-oauth-attestation-based-client-auth）。ボディにもヘッダにもシークレットを載せないため、配布物にシークレットを埋め込めないネイティブアプリで使います。

JWT認証（client_secret_jwt / private_key_jwt）では、以下のクレームを含むJWTを生成し、次のパラメータを使用して送信してください：

client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion: 署名済みJWT

認証に失敗した場合は 400 Bad Request が返されます（エラーコードは下記 400 を参照）。

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

header Parameters

Authorization	string Basic認証ヘッダー（client_secret_basic認証方式用）。 `Basic base64(client_id:client_secret)` 形式で送信します。
OAuth-Client-Attestation	string <jwt> Client Attestation JWT（`attest_jwt_client_auth` 用）。 Client Attester が発行した JWT で、`cnf.jwk` にクライアントインスタンスの公開鍵を持ちます。 `OAuth-Client-Attestation-PoP` と必ず対で送信します（片方だけのリクエストは拒否されます）。 `typ` は `oauth-client-attestation+jwt`。
OAuth-Client-Attestation-PoP	string <jwt> Client Attestation PoP JWT（`attest_jwt_client_auth` 用）。 `OAuth-Client-Attestation` の `cnf.jwk` に対応する秘密鍵で署名し、そのインスタンスが鍵を保持していることを示します。`typ` は `oauth-client-attestation-pop+jwt`。テナントが `client_attestation_challenge_required` を有効にしている場合、 `challenge` クレームにチャレンジエンドポイントで得た値が必要です。

Request Body schema: application/x-www-form-urlencoded
required

通常の OAuth 2.0/OpenID Connect 認可リクエストと同じパラメータ。 authorization_details (RAR) や大きなパラメータも安全に送信可能。

client_id

required

string

クライアント識別子。事前に認可サーバーに登録されたもの。

client_secret

string <password>

client_secret_post 認証方式の場合に使用するクライアントシークレット。 client_secret_basic を使用する場合は Authorization ヘッダーで送信。

response_type

required

string

Value: "code"

OAuth 2.0 レスポンスタイプ。認可コードフローでは code。

scope

required

string

要求するスコープのスペース区切りリスト。 OpenID Connect では openid が必須。

redirect_uri

required

string <uri>

認可完了後のリダイレクト先URI。クライアント登録時に指定されたもののいずれかである必要があります。

state

string

CSRF攻撃を防ぐための不透明な値。認可レスポンスでそのまま返却されます。

response_mode

string

Enum: "query" "fragment" "form_post"

認可レスポンスの返却方法。

nonce

string

OpenID Connect でリプレイ攻撃を防ぐための値。 ID Token の nonce クレームに含まれます。

display

string

Enum: "page" "popup" "touch" "wap"

認証・同意画面の表示方法を指定。

prompt

string

ユーザー認証・同意の要求方法。

max_age

integer

許容される認証の最大経過時間（秒）。

ui_locales

string

UI表示に使用する言語の優先順位（BCP47形式、スペース区切り）。

id_token_hint

string

以前に取得したID Tokenをヒントとして渡す場合。

login_hint

string

ユーザーを識別するヒント。IDやメールアドレスなど

login_hint

login_hint には複数の拡張形式をサポートし、柔軟なユーザー特定が可能です。

フォーマット	意味	例
`sub:<subject>`	内部ユーザーIDで直接識別	`sub:abc123`
`ex-sub:<subject>,idp:<id-provider>`	外部IdPのサブジェクトで識別	`ex-sub:ex-idp123,idp:ex-idp`
`device:<deviceId>,idp:<id-provider>`	認証デバイスで識別	`device:device123,idp:ex-idp`
`email:<email>,idp:<id-provider>`	メールアドレスによる識別	`email:foo@example.com,idp:idp-server`
`phone:<number>,idp:<id-provider>`	電話番号による識別	`phone:09012345678,idp:idp-server`

idp-provider のデフォルト値は idp-server。

acr_values

string

要求する認証コンテキストクラス参照値（スペース区切り）。

claims

string

要求する個々のクレームを指定するJSONオブジェクト。

registration

string

動的クライアント登録情報（JSON形式）。

request

string

署名済みリクエストオブジェクト（JWT形式）。

request_uri

string <uri>

リクエストオブジェクトを取得するためのURI。

code_challenge

string

PKCE code challenge（RFC 7636）。 code_verifier から生成されたハッシュ値。

code_challenge_method

string

Enum: "plain" "S256"

PKCE code challenge の生成方法。S256 を推奨。

authorization_details

string

Rich Authorization Requests (RFC 9396) で定義される詳細な認可要求。 JSON配列形式の文字列。

Responses

Request samples

Payload

Content type

application/x-www-form-urlencoded

Example

基本的な OpenID Connect リクエスト

client_id=example_client&response_type=code&scope=openid%20profile%20email&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

Response samples

Content type

application/json

{"request_uri": "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LtdVcSU",
"expires_in": 300
}

認可リクエスト

クライアントアプリケーションがエンドユーザーの認可を取得するためのエンドポイント。 OpenID Connect Core 1.0 Section 3 に準拠。

本エンドポイントは、以下の OpenID Connect 認可フローに対応しています：

Authorization Code Flow（認可コードフロー）
Implicit Flow（インプリシットフロー）
Hybrid Flow（ハイブリッドフロー）

認可リクエストを受け取ると、本サーバーはエンドユーザーとの認証・同意を行うための認可画面URLをレスポンス(302)として返却します。このURLにクライアントアプリケーションがリダイレクトすることで、ユーザーとの対話（認証・同意）が開始されます。

query Parameters

response_type

required

string

Enum: "code" "id_token" "token" "code id_token" "code token" "id_token token" "code id_token token"

使用する認可フローの種類。OpenID Connectでは通常 "code" を使用。他にも "id_token" や "token" を組み合わせてハイブリッドフローも可能。 OAuth 2.0 / OpenID Connect 仕様に準拠。

client_id

required

string

クライアントアプリケーションに割り当てられた一意のID。

redirect_uri

required

string <uri>

認可後にユーザーをリダイレクトするURI。事前に登録されている必要がある。

scope

required

string

要求するスコープ。複数設定する場合は半角スペース区切り。OpenID Connectでは "openid" を含める必要がある。例: "openid profile email"

state

required

string

CSRF対策などのために利用されるクライアントからの任意文字列。

nonce

string

リプレイアタック防止のためのランダムな文字列（IDトークンの検証に使用）。

display

string

認可画面の表示方法を指定（popup / page / touch / wap）。基本は省略可能。

prompt

string

認可サーバーの動作を制御するためのヒント。例: "login", "none", "consent", "select_account"

max_age

integer

最後の認証からの経過秒数の最大値。これを超えていると再認証が要求される。

ui_locales

string

認可画面のUI言語設定。複数指定可能（例: "ja en-US fr"）。

id_token_hint

string

特定のユーザーを示唆するIDトークン。ログインセッション再利用やユーザー固定に使用。

login_hint

string

Example: login_hint=email:user@example.com,idp:idp-server

ユーザーを識別するヒント。IDやメールアドレスなど

login_hint

login_hint には複数の拡張形式をサポートし、柔軟なユーザー特定が可能です。

フォーマット	意味	例
`sub:<subject>`	内部ユーザーIDで直接識別	`sub:abc123`
`ex-sub:<subject>,idp:<id-provider>`	外部IdPのサブジェクトで識別	`ex-sub:ex-idp123,idp:ex-idp`
`device:<deviceId>,idp:<id-provider>`	認証デバイスで識別	`device:device123,idp:ex-idp`
`email:<email>,idp:<id-provider>`	メールアドレスによる識別	`email:foo@example.com,idp:idp-server`
`phone:<number>,idp:<id-provider>`	電話番号による識別	`phone:09012345678,idp:idp-server`

idp-provider のデフォルト値は idp-server。

acr_values

string

必要とされる認証レベル（例: "urn:mfa:required" など）を指定。認証強度ポリシーの制御に使用。

request

string

リクエストパラメータを含むJWT。署名・暗号化可能な "Request Object"。認可リクエストの一貫性とセキュリティ向上に使用。

request_uri

string

事前登録されたリクエストオブジェクトのURI。リクエストサイズ削減やセキュリティ強化に利用される。

claims

string

特定の Claim を id_token や userinfo に含めるようリクエストするためのパラメータ。値は JSON 形式でエンコードされており、form-urlencoded によって送信される。

以下のような構造で、IDトークンやUserInfoに含めたいClaimを指定できる：

例: { "userinfo": { "email": { "essential": true }, "email_verified": { "essential": true } }, "id_token": { "auth_time": { "essential": true }, "acr": { "values": ["urn:mace:incommon:iap:silver"] } } }

essential: Claim が必須であることを示す（true/false）
value: 特定の値を要求
values: 候補値の配列を指定
null: 任意要求（Voluntary Claim）

claims_locales と併用することで、言語タグ指定のClaim要求も可能。

◆補足 claims パラメータは、Authorization Request 時に OpenID Provider に対して必要な Claim（属性）を明示的に要求するために使用されます。

userinfo セクション：UserInfoエンドポイントに返されるClaimを指定
id_token セクション：IDトークンに含まれるClaimを指定
essential フラグで必須／任意を区別
value / values による値制約
claims_locales と併用すれば、言語指定付きのClaimも要求可能

仕様：OpenID Connect Core 1.0 Section 5.5 を参照。

verified_claims（身元確認済みクレーム / OIDC4IDA）

userinfo / id_token 配下に verified_claims を指定すると、OpenID Connect for Identity Assurance 1.0 に従って身元確認済みクレームを要求できる。verification （必須要素 trust_framework）と claims のネスト構造で指定し、value / values 制約や §5.7 の選択的省略（不一致・未保持クレームの省略）が適用される。

例: { "userinfo": { "verified_claims": { "verification": { "trust_framework": { "value": "eidas" } }, "claims": { "given_name": null, "family_name": null } } } }

◆優先順位 idp-server には verified_claims:<claim> プレフィックスのスコープによる独自拡張もあり、 UserInfo ではどちらも同一のトップレベル verified_claims キーを生成する。1リクエストで両方を指定した場合は claims パラメータ（標準）を優先し、verified_claims:* スコープ（独自拡張）側は出力しない。

仕様：OpenID Connect for Identity Assurance 1.0 を参照。

code_challenge

string

PKCE用のチャレンジ文字列。SHA256などで code_verifier を変換した値。 publicクライアント（SPAやモバイル）では使用が推奨される。

code_challenge_method

string

Enum: "plain" "S256"

code_challenge の生成に使用したメソッド。推奨は "S256"。省略時は "plain" 扱いになる。

authorization_details

string

RFC 9396（リッチ認可リクエスト）で定義された authorization detail オブジェクトの配列。のJSON文字列

Responses

Response samples

429
500
503
504

Content type

application/json

Example

スロットリング（秒間リクエスト制限）

{"message": "Too Many Requests"
}

認可リクエスト（POST）

クライアントアプリケーションがエンドユーザーの認可を取得するためのエンドポイント（POSTメソッド）。

仕様準拠

RFC 6749 Section 3.1: Authorization ServerはGETメソッドをサポートしなければならず（MUST）、POSTメソッドもサポートしてもよい（MAY）
OIDC Core 1.0 Section 3.1.2.1: Authorization ServerはGETとPOSTの両方をサポートしなければならない（MUST）

POSTメソッドの利点

URLの長さ制限を回避: authorization_details や claims などの長いパラメータに対応
セキュリティ向上: ブラウザ履歴やプロキシログにセンシティブなパラメータが残らない
プライバシー保護: login_hint などの個人情報がURLに含まれない

パラメータ

GETメソッドと同じパラメータを application/x-www-form-urlencoded 形式でリクエストボディに含めます。

参考

Request Body schema: application/x-www-form-urlencoded
required

response_type required	string レスポンスタイプ（code, id_token, token等）
client_id required	string クライアントID
redirect_uri required	string <uri> リダイレクトURI
scope required	string 要求するスコープ（スペース区切り）
state	string CSRF対策用のstate値
nonce	string リプレイ攻撃防止用のnonce値
display	string Enum: "page" "popup" "touch" "wap" 認証画面の表示形式
prompt	string Enum: "none" "login" "consent" "select_account" 認証プロンプトの動作
max_age	integer 最大認証経過時間（秒）
ui_locales	string UI表示言語（スペース区切り）
id_token_hint	string IDトークンのヒント
login_hint	string ログインヒント（メールアドレス等）
acr_values	string 要求する認証コンテキストクラス参照値
claims	string 要求するクレーム（JSON形式）
request	string JWTリクエストオブジェクト
request_uri	string <uri> リクエストオブジェクトのURI
code_challenge	string PKCEコードチャレンジ
code_challenge_method	string Default: "plain" Enum: "plain" "S256" コードチャレンジメソッド
authorization_details	string 認可詳細（JSON配列形式）

Responses

Response samples

429
500
503
504

Content type

application/json

Example

スロットリング（秒間リクエスト制限）

{"message": "Too Many Requests"
}

トークン

OAuth 2.0 / OpenID Connect におけるトークン管理に関連するエンドポイント群です。

クライアントがアクセストークンやIDトークンを取得するための トークンリクエスト
トークンを検証する トークンイントロスペクション
トークンを無効化する トークンリボケーション

を含み、ID連携・アクセス制御における中心的な役割を担います。

これらのエンドポイントを通じて、クライアントと認可サーバー間のセキュアな認証・認可のやりとりが実現されます。

📘 関連仕様：

トークンリクエスト

grant_typeに応じて、トークンを取得します。サポートするgrant_type

authorization_code: 認可コードフローGrant
refresh_token: リフレッシュトークンGrant
password: リソースオーナーパスワードクレデンシャルズGrant
client_credentials: クライアントクレデンシャルズGrant
urn:openid:params:grant-type:ciba: CIBAフローGrant

このエンドポイントはクライアント認証を必要とします。以下のクライアント認証方式に対応しています（Client Authentication）：

client_secret_basic：AuthorizationヘッダにBasic認証形式で client_id / client_secret を送信します（デフォルト）。
client_secret_post：client_id と client_secret をフォームパラメータとしてリクエストボディに含めます。
client_secret_jwt：client_secret を共通鍵として署名した JWT を client_assertion として送信します。
private_key_jwt：登録済みの公開鍵に対応する秘密鍵で署名した JWT を client_assertion として送信します。
none：認証を行いません。PKCEを使用するPublicクライアント向け。
tls_client_auth（mTLS）：クライアント証明書を使って双方向TLS認証を行います。サーバーは証明書のサブジェクトなどでクライアントを識別します。
self_signed_tls_client_auth（自己署名TLS）: 自己署名のクライアント証明書を用いたTLS認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。
attest_jwt_client_auth：Client Attestation JWT と Client Attestation PoP JWT をOAuth-Client-Attestation / OAuth-Client-Attestation-PoP ヘッダで送信します（draft-ietf-oauth-attestation-based-client-auth）。ボディにもヘッダにもシークレットを載せないため、配布物にシークレットを埋め込めないネイティブアプリで使います。

JWT認証（client_secret_jwt / private_key_jwt）では、以下のクレームを含むJWTを生成し、次のパラメータを使用して送信してください：

client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion: 署名済みJWT

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

header Parameters

Authorization	string Basic認証ヘッダー（client_secret_basic認証方式用）。 `Basic base64(client_id:client_secret)` 形式で送信します。
OAuth-Client-Attestation	string <jwt> Client Attestation JWT（`attest_jwt_client_auth` 用）。 Client Attester が発行した JWT で、`cnf.jwk` にクライアントインスタンスの公開鍵を持ちます。 `OAuth-Client-Attestation-PoP` と必ず対で送信します（片方だけのリクエストは拒否されます）。 `typ` は `oauth-client-attestation+jwt`。
OAuth-Client-Attestation-PoP	string <jwt> Client Attestation PoP JWT（`attest_jwt_client_auth` 用）。 `OAuth-Client-Attestation` の `cnf.jwk` に対応する秘密鍵で署名し、そのインスタンスが鍵を保持していることを示します。`typ` は `oauth-client-attestation-pop+jwt`。テナントが `client_attestation_challenge_required` を有効にしている場合、 `challenge` クレームにチャレンジエンドポイントで得た値が必要です。

Request Body schema: application/x-www-form-urlencoded
required

One of

grant_type required	string 使用するグラントタイプ。認可コードフローにおいては "authorization_code"。
code required	string 認可エンドポイントから受け取った認可コード。
redirect_uri	string <uri> 認可リクエスト時に指定した redirect_uri と一致させる必要がある。 ※認可リクエスト時に redirect_uri を指定した場合は必須。
client_id	string クライアントの識別子。認証方式がclient_secret_basicの場合は省略可能。
client_secret	string クライアントのシークレット。認証方式がclient_secret_postの場合に設定する。
code_verifier	string PKCEで使用されるチャレンジ検証用の文字列。認可リクエストで code_challenge を指定した場合は必須。
client_assertion_type	string Value: "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" JWT認証（client_secret_jwt / private_key_jwt）で使用するアサーションタイプ。固定値: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion	string JWT認証で使用する署名済みJWTアサーション。 client_secret_jwt: client_secretで署名 private_key_jwt: 登録済み秘密鍵で署名

Responses

error	意味
`invalid_client_attestation`	Client Attestation JWT / PoP JWT の検証に失敗した（署名、`typ`、`aud`、`iat` など）
`use_fresh_attestation`	Client Attestation JWT の期限が切れている

Response samples

Content type

application/json

Example

TokenResponse

{"access_token": "string",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "string",
"id_token": "string",
"scope": "openid profile email",
"authorization_details": [{"type": "string",
"locations": ["string"
],
"actions": ["string"
],
"datatypes": ["string"
],
"identifier": "string",
"privileges": ["string"
]
}
]
}

トークン検証

アクセストークンやリフレッシュトークンの状態を確認するためのエンドポイントです。クライアントは自身が発行されたトークンの有効性や関連情報を照会できます。

📘 RFC 7662 準拠: OAuth 2.0 Token Introspection

クライアント認証

このエンドポイントは クライアント認証が必須 です。以下の認証方法をサポートしています：

client_secret_basic：AuthorizationヘッダにBasic認証形式で client_id / client_secret を送信します（デフォルト）。
client_secret_post：client_id と client_secret をフォームパラメータとしてリクエストボディに含めます。
client_secret_jwt：client_secret を共通鍵として署名した JWT を client_assertion として送信します。
private_key_jwt：登録済みの公開鍵に対応する秘密鍵で署名した JWT を client_assertion として送信します。
tls_client_auth（mTLS）：クライアント証明書を使って双方向TLS認証を行います。サーバーは証明書のサブジェクトなどでクライアントを識別します。
self_signed_tls_client_auth（自己署名TLS）: 自己署名のクライアント証明書を用いたTLS認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。
attest_jwt_client_auth：Client Attestation JWT と Client Attestation PoP JWT をOAuth-Client-Attestation / OAuth-Client-Attestation-PoP ヘッダで送信します（draft-ietf-oauth-attestation-based-client-auth）。ボディにもヘッダにもシークレットを載せないため、配布物にシークレットを埋め込めないネイティブアプリで使います。

JWT認証（client_secret_jwt / private_key_jwt）では、以下のクレームを含むJWTを生成し、次のパラメータを使用して送信してください：

client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion: 署名済みJWT

認証に失敗した場合は 401 Unauthorized が返されます（下記 401 を参照）。

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

header Parameters

Authorization	string Basic認証ヘッダー（client_secret_basic認証方式用）。 `Basic base64(client_id:client_secret)` 形式で送信します。
OAuth-Client-Attestation	string <jwt> Client Attestation JWT（`attest_jwt_client_auth` 用）。 Client Attester が発行した JWT で、`cnf.jwk` にクライアントインスタンスの公開鍵を持ちます。 `OAuth-Client-Attestation-PoP` と必ず対で送信します（片方だけのリクエストは拒否されます）。 `typ` は `oauth-client-attestation+jwt`。
OAuth-Client-Attestation-PoP	string <jwt> Client Attestation PoP JWT（`attest_jwt_client_auth` 用）。 `OAuth-Client-Attestation` の `cnf.jwk` に対応する秘密鍵で署名し、そのインスタンスが鍵を保持していることを示します。`typ` は `oauth-client-attestation-pop+jwt`。テナントが `client_attestation_challenge_required` を有効にしている場合、 `challenge` クレームにチャレンジエンドポイントで得た値が必要です。

Request Body schema: application/x-www-form-urlencoded
required

token required	string 検証対象となるアクセストークンまたはリフレッシュトークン。
token_type_hint	string Enum: "access_token" "refresh_token" トークンの種別に関するヒント（省略可能）。
client_id	string クライアント識別子。client_secret_post認証やmTLS認証で使用します。 client_secret_basic認証の場合はAuthorizationヘッダで送信されるため省略可能。
client_secret	string クライアントシークレット。client_secret_post認証でのみ使用します。 client_secret_basic認証の場合はAuthorizationヘッダで送信されます。
client_assertion_type	string Value: "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" JWT認証（client_secret_jwt / private_key_jwt）で使用するアサーションタイプ。固定値: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion	string JWT認証で使用する署名済みJWTアサーション。 client_secret_jwt: client_secretで署名 private_key_jwt: 登録済み秘密鍵で署名

Responses

Response samples

Content type

application/json

{"active": true,
"scope": "string",
"client_id": "string",
"username": "string",
"token_type": "string",
"exp": 0,
"iat": 0,
"nbf": 0,
"sub": "string",
"aud": "string",
"iss": "string",
"jti": "string",
"acr": "urn:mace:incommon:iap:gold",
"amr": ["fido-uaf"
],
"auth_time": 0,
"authorization_details": [{ }
],
"ex_sub": "string",
"property1": null,
"property2": null
}

トークン検証（拡張）

アクセストークンやリフレッシュトークンの状態を、リソースサーバー（RS）がクライアントから受け取ったリクエストの正当性込みで検証する拡張エンドポイントです。標準仕様（RFC 7662）に加えて、以下も同時に検証します：

要求スコープがアクセストークンに含まれているか
mTLS sender-constrained: クライアント証明書のサムプリントがトークンの cnf.x5t#S256 と一致しているか（RFC 8705 §3）
DPoP sender-constrained: DPoP proof JWT の鍵サムプリント（jkt）がトークンの cnf.jkt と一致し、htm / htu / ath 等の検証も成立しているか（RFC 9449 §7）

トークンが有効な場合は、標準仕様に沿ったレスポンスを返却します。トークンが無効な場合は、エラーの原因を含めてレスポンスを返却します。

📘 RFC 7662 拡張 + RFC 8705 §3 + RFC 9449 §7: OAuth 2.0 Token Introspection の拡張実装

RS forwarding pattern（重要）

このエンドポイントは Resource Server forwarding pattern で設計されており、RS はクライアントが RS のリソースエンドポイントに対して提示した以下の artifact を、すべて HTTP リクエストボディの form パラメータとして AS に forward する必要があります：

client_cert — クライアントが RS に提示した PEM 形式の TLS クライアント証明書（mTLS 検証用）
dpop_proof — クライアントが RS に提示した DPoP proof JWT（DPoP 検証用）
dpop_htm — クライアントが RS に対して使用した HTTP メソッド（dpop_proof の htm クレームと一致すること）
dpop_htu — クライアントが RS に対して使用したリソース URI（dpop_proof の htu クレームと一致すること）

⚠️ 注意: このエンドポイントは HTTP リクエストヘッダの DPoP を意図的に参照しません。DPoP ヘッダの値は「RS 自身がこの introspection 呼び出しのために生成した proof」となり、検証対象である「クライアント → RS」のリソースアクセスとは別物だからです。同様に、TLS 接続層の x-ssl-cert ヘッダは「RS が AS に対して mTLS 認証する際の RS 自身のクライアント証明書」であり、client_cert body パラメータ（クライアントの token-binding 証明書）とは独立しています。

エラーハンドリング

このエンドポイントでは、トークン無効・スコープ不足・sender-constraint 不一致等の トークンに関するエラーが HTTP 200 で返却 されます（HTTP 403 は返りません）。エラーの判別には active: false と error / status_code フィールドを使用してください。呼び出し元（リソースサーバー）自身のクライアント認証の失敗だけは、HTTP 401 で active を含まずに返ります（RFC 7662 Section 2.3）。 status_code はリソースサーバーがエンドユーザーに返すべき論理的な HTTP ステータスの参考値です。

クライアント認証

このエンドポイントは クライアント認証が必須 です。以下の認証方法をサポートしています：

client_secret_basic：AuthorizationヘッダにBasic認証形式で client_id / client_secret を送信します（デフォルト）。
client_secret_post：client_id と client_secret をフォームパラメータとしてリクエストボディに含めます。
client_secret_jwt：client_secret を共通鍵として署名した JWT を client_assertion として送信します。
private_key_jwt：登録済みの公開鍵に対応する秘密鍵で署名した JWT を client_assertion として送信します。
tls_client_auth（mTLS）：クライアント証明書を使って双方向TLS認証を行います。サーバーは証明書のサブジェクトなどでクライアントを識別します。
self_signed_tls_client_auth（自己署名TLS）: 自己署名のクライアント証明書を用いたTLS認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。
attest_jwt_client_auth：Client Attestation JWT と Client Attestation PoP JWT をOAuth-Client-Attestation / OAuth-Client-Attestation-PoP ヘッダで送信します（draft-ietf-oauth-attestation-based-client-auth）。ボディにもヘッダにもシークレットを載せないため、配布物にシークレットを埋め込めないネイティブアプリで使います。

JWT認証（client_secret_jwt / private_key_jwt）では、以下のクレームを含むJWTを生成し、次のパラメータを使用して送信してください：

client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion: 署名済みJWT

認証に失敗した場合は 401 Unauthorized が返されます（下記 401 を参照）。

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

header Parameters

Authorization	string Basic認証ヘッダー（client_secret_basic認証方式用）。 `Basic base64(client_id:client_secret)` 形式で送信します。
OAuth-Client-Attestation	string <jwt> Client Attestation JWT（`attest_jwt_client_auth` 用）。 Client Attester が発行した JWT で、`cnf.jwk` にクライアントインスタンスの公開鍵を持ちます。 `OAuth-Client-Attestation-PoP` と必ず対で送信します（片方だけのリクエストは拒否されます）。 `typ` は `oauth-client-attestation+jwt`。
OAuth-Client-Attestation-PoP	string <jwt> Client Attestation PoP JWT（`attest_jwt_client_auth` 用）。 `OAuth-Client-Attestation` の `cnf.jwk` に対応する秘密鍵で署名し、そのインスタンスが鍵を保持していることを示します。`typ` は `oauth-client-attestation-pop+jwt`。テナントが `client_attestation_challenge_required` を有効にしている場合、 `challenge` クレームにチャレンジエンドポイントで得た値が必要です。

Request Body schema: application/x-www-form-urlencoded
required

token required	string 検証対象となるアクセストークンまたはリフレッシュトークン。
token_type_hint	string Enum: "access_token" "refresh_token" トークンの種別に関するヒント（省略可能）。
scope	string アクセストークンに含まれているかを検証したいスコープ。複数設定する場合は半角スペース区切り。指定したスコープがない場合はエラーを返却する。
client_cert	string クライアントが RS のリソースエンドポイントに対して提示した PEM 形式の TLS クライアント証明書。アクセストークンの `cnf.x5t#S256`（RFC 8705 §3 token binding）との一致を検証します。注: TLS 接続層の `x-ssl-cert` ヘッダは「RS が AS に対して mTLS 認証する際の RS 自身の証明書」であり、このパラメータ（クライアントの token-binding 証明書）とは独立しています。
dpop_proof	string クライアントが RS のリソースエンドポイントに対して提示した DPoP proof JWT（RFC 9449 §7）。アクセストークンの `cnf.jkt` との一致、および `htm` / `htu` / `ath` / `iat` / `jti` 等の検証を実施します。注: HTTP リクエストヘッダの `DPoP` は意図的に参照されません。ヘッダ値は「RS 自身がこの introspection 呼び出しのために生成した proof」となり、検証対象である「クライアント → RS」のリソースアクセスとは別物だからです。
dpop_htm	string クライアントが RS に対して使用した HTTP メソッド（例: `GET`, `POST`）。 `dpop_proof` の `htm` クレームと一致することが要求されます。省略時のデフォルトは `POST`。
dpop_htu	string クライアントが RS に対して使用したリソース URI。 `dpop_proof` の `htu` クレームと一致することが要求されます。
client_id	string クライアント識別子。client_secret_post認証やmTLS認証で使用します。 client_secret_basic認証の場合はAuthorizationヘッダで送信されるため省略可能。
client_secret	string クライアントシークレット。client_secret_post認証でのみ使用します。 client_secret_basic認証の場合はAuthorizationヘッダで送信されます。
client_assertion_type	string Value: "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" JWT認証（client_secret_jwt / private_key_jwt）で使用するアサーションタイプ。固定値: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion	string JWT認証で使用する署名済みJWTアサーション。 client_secret_jwt: client_secretで署名 private_key_jwt: 登録済み秘密鍵で署名

Responses

Response samples

Content type

application/json

Example

TokenIntrospectionResponse

{"active": true,
"scope": "string",
"client_id": "string",
"username": "string",
"token_type": "string",
"exp": 0,
"iat": 0,
"nbf": 0,
"sub": "string",
"aud": "string",
"iss": "string",
"jti": "string",
"acr": "urn:mace:incommon:iap:gold",
"amr": ["fido-uaf"
],
"auth_time": 0,
"authorization_details": [{ }
],
"ex_sub": "string",
"property1": null,
"property2": null
}

トークン失効

発行済みのアクセストークンやリフレッシュトークンを無効化（取り消し）するためのエンドポイントです。クライアントは自分が発行したトークンのみをリボーク可能です。

📘 RFC 7009 準拠: OAuth 2.0 Token Revocation

クライアント認証

このエンドポイントは クライアント認証が必須 です。以下の認証方法をサポートしています：

client_secret_basic：AuthorizationヘッダにBasic認証形式で client_id / client_secret を送信します（デフォルト）。
client_secret_post：client_id と client_secret をフォームパラメータとしてリクエストボディに含めます。
client_secret_jwt：client_secret を共通鍵として署名した JWT を client_assertion として送信します。
private_key_jwt：登録済みの公開鍵に対応する秘密鍵で署名した JWT を client_assertion として送信します。
tls_client_auth（mTLS）：クライアント証明書を使って双方向TLS認証を行います。サーバーは証明書のサブジェクトなどでクライアントを識別します。
self_signed_tls_client_auth（自己署名TLS）: 自己署名のクライアント証明書を用いたTLS認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。
attest_jwt_client_auth：Client Attestation JWT と Client Attestation PoP JWT をOAuth-Client-Attestation / OAuth-Client-Attestation-PoP ヘッダで送信します（draft-ietf-oauth-attestation-based-client-auth）。ボディにもヘッダにもシークレットを載せないため、配布物にシークレットを埋め込めないネイティブアプリで使います。

JWT認証（client_secret_jwt / private_key_jwt）では、以下のクレームを含むJWTを生成し、次のパラメータを使用して送信してください：

client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion: 署名済みJWT

認証に失敗した場合は 401 Unauthorized が返されます。

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

header Parameters

Authorization	string Basic認証ヘッダー（client_secret_basic認証方式用）。 `Basic base64(client_id:client_secret)` 形式で送信します。
OAuth-Client-Attestation	string <jwt> Client Attestation JWT（`attest_jwt_client_auth` 用）。 Client Attester が発行した JWT で、`cnf.jwk` にクライアントインスタンスの公開鍵を持ちます。 `OAuth-Client-Attestation-PoP` と必ず対で送信します（片方だけのリクエストは拒否されます）。 `typ` は `oauth-client-attestation+jwt`。
OAuth-Client-Attestation-PoP	string <jwt> Client Attestation PoP JWT（`attest_jwt_client_auth` 用）。 `OAuth-Client-Attestation` の `cnf.jwk` に対応する秘密鍵で署名し、そのインスタンスが鍵を保持していることを示します。`typ` は `oauth-client-attestation-pop+jwt`。テナントが `client_attestation_challenge_required` を有効にしている場合、 `challenge` クレームにチャレンジエンドポイントで得た値が必要です。

Request Body schema: application/x-www-form-urlencoded
required

token required	string 無効化するアクセストークンまたはリフレッシュトークン。
token_type_hint	string Enum: "access_token" "refresh_token" トークンの種類に関するヒント（省略可能）。
client_id	string クライアント識別子。client_secret_post認証やmTLS認証で使用します。 client_secret_basic認証の場合はAuthorizationヘッダで送信されるため省略可能。
client_secret	string クライアントシークレット。client_secret_post認証でのみ使用します。 client_secret_basic認証の場合はAuthorizationヘッダで送信されます。
client_assertion_type	string Value: "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" JWT認証（client_secret_jwt / private_key_jwt）で使用するアサーションタイプ。固定値: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion	string JWT認証で使用する署名済みJWTアサーション。 client_secret_jwt: client_secretで署名 private_key_jwt: 登録済み秘密鍵で署名

Responses

Response samples

429
500
503
504

Content type

application/json

Example

スロットリング（秒間リクエスト制限）

{"message": "Too Many Requests"
}

OIDC

OpenID Connect は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものです。このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証可能にします。

また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することにします。

📘 関連仕様:
OpenID Connect Core 1.0

ユーザーInfo

認証されたエンドユーザーのプロフィール情報を返す。 OpenID Connect Core 1.0 Section 5 に準拠。

返却可能なクレーム（ユーザー情報項目）:

OpenID Connect Discovery（/.well-known/openid-configuration）の claims_supported で確認できます
標準クレーム例: sub, name, email, email_verified, preferred_username, phone_number など
実際に返却されるクレームは、scope パラメータまたは claims パラメータでの要求内容に依存します

Authorizations:

bearerAuth

Responses

Response samples

200
429
500
503
504

Content type

application/json

{"sub": "string",
"name": "string",
"given_name": "string",
"family_name": "string",
"middle_name": "string",
"nickname": "string",
"preferred_username": "string",
"profile": "http://example.com",
"picture": "http://example.com",
"website": "http://example.com",
"email": "user@example.com",
"email_verified": true,
"gender": "male",
"birthdate": "string",
"zoneinfo": "string",
"locale": "string",
"phone_number": "string",
"phone_number_verified": true,
"address": {"formatted": "string",
"street_address": "string",
"locality": "string",
"region": "string",
"postal_code": "string",
"country": "string"
},
"updated_at": 0
}

ユーザーInfo

認証されたエンドユーザーのプロフィール情報を返す。 OpenID Connect Core 1.0 Section 5 に準拠。

返却可能なクレーム（ユーザー情報項目）:

OpenID Connect Discovery（/.well-known/openid-configuration）の claims_supported で確認できます
標準クレーム例: sub, name, email, email_verified, preferred_username, phone_number など
実際に返却されるクレームは、scope パラメータまたは claims パラメータでの要求内容に依存します

Authorizations:

bearerAuth

Responses

Response samples

200
429
500
503
504

Content type

application/json

{"sub": "string",
"name": "string",
"given_name": "string",
"family_name": "string",
"middle_name": "string",
"nickname": "string",
"preferred_username": "string",
"profile": "http://example.com",
"picture": "http://example.com",
"website": "http://example.com",
"email": "user@example.com",
"email_verified": true,
"gender": "male",
"birthdate": "string",
"zoneinfo": "string",
"locale": "string",
"phone_number": "string",
"phone_number_verified": true,
"address": {"formatted": "string",
"street_address": "string",
"locality": "string",
"region": "string",
"postal_code": "string",
"country": "string"
},
"updated_at": 0
}

RP-Initiated Logout エンドポイント

OpenID Connect RP-Initiated Logout 1.0 に準拠したログアウトエンドポイント。

Relying Party（RP）からの要求に応じて、エンドユーザーを OpenID Provider（OP）からログアウトさせ、オプションで post_logout_redirect_uri にリダイレクトします。

仕様のポイント:

冪等性: 同じログアウトリクエストを複数回実行しても安全
推奨パラメータ: id_token_hint による適切なセッション特定
セキュリティ: 無効なパラメータでも処理を継続（DoS攻撃防止）

処理フロー:

リクエストパラメータの検証
id_token_hint によるセッション特定（推奨）
エンドユーザーのセッション終了
post_logout_redirect_uri が有効な場合はリダイレクト

エンドユーザー体験:

OPでのログアウト確認画面表示（推奨）
適切な言語でのメッセージ表示（ui_locales 対応）

📘 関連仕様: OpenID Connect RP-Initiated Logout 1.0

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

query Parameters

post_logout_redirect_uri	string <uri> Example: post_logout_redirect_uri=https://client.example.com/logout-callback ログアウト完了後のリダイレクト先URI。セキュリティ検証（オープンリダイレクト対策）: RP-Initiated Logout 1.0 Section 3 に基づき、以下の検証を行います： "The OP also MUST NOT perform post-logout redirection if the post_logout_redirect_uri value supplied does not exactly match one of the previously registered post_logout_redirect_uris values." クライアント識別必須: `client_id` または `id_token_hint` でクライアントを識別できない場合、リダイレクトを実行しません事前登録必須: クライアントに `post_logout_redirect_uris` が登録されていない場合、リダイレクトを実行しません完全一致検証: 指定されたURIが登録済みURIと完全一致しない場合、リダイレクトを実行しません検証失敗時の動作: HTTP 400 エラーを返却攻撃者による任意URLへのリダイレクト（オープンリダイレクト）を防止推奨事項: HTTPS スキームを使用すること（Section 2: "SHOULD use the https scheme"）本番環境では HTTP スキームを許可しないこと
id_token_hint	string Example: id_token_hint=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... OPが以前にRPに発行したIDトークン（推奨パラメータ）。 RP-Initiated Logout 1.0 仕様での位置づけ: エンドユーザーの現在のセッションを示すヒントセッション特定の精度向上セキュリティ強化（正当なログアウト要求の証明）注意事項: 提供されない場合もログアウト処理は継続（DoS攻撃防止）無効なトークンでも処理を中断しない
logout_hint	string Example: logout_hint=user123@example.com エンドユーザーに関する追加のログアウトヒント（オプション）。用途: ユーザー識別の補助情報特定のアカウントやセッションの指定カスタムログアウト処理のトリガー実装依存: OPの実装により具体的な利用方法が決定されます。
client_id	string Example: client_id=my-client-app OAuth 2.0 クライアント識別子（オプション）。使用ケース: 複数クライアント環境でのログアウト元の特定クライアント別のログアウト処理監査ログでのクライアント追跡通常は `id_token_hint` からクライアントを特定できるため、明示的な指定は必須ではありません。
state	string Example: state=xyz789state RPが生成する不透明な状態値（オプション）。 RP-Initiated Logout 1.0 での役割: リクエスト・レスポンスの関連付け CSRF攻撃の防止 RPでのセッション状態管理ログアウト完了時にリダイレクトURIにそのまま付加されます。
ui_locales	string Example: ui_locales=ja JP en US エンドユーザーインターフェースの優先言語（オプション）。仕様対応: RFC 5646 言語タグ形式スペース区切りで優先順位指定ログアウト確認画面の言語制御例: "ja JP en US" （日本語優先、英語フォールバック）

Responses

Response samples

400
429
500
503
504

Content type

application/json

Example

クライアント識別不可

{"error": "invalid_request",
"error_description": "post_logout_redirect_uri provided but client could not be identified"
}

Client Attestation

Attestation-Based Client Authentication（attest_jwt_client_auth）で使うチャレンジの発行。

クライアントインスタンスの登録は別仕様です → Client Instance 登録API

Client Attestation チャレンジの発行

Client Attestation PoP JWT の challenge クレームに入れる値を発行します（draft-ietf-oauth-attestation-based-client-auth-11 Section 6.3）。

テナントで client_attestation_challenge_required を有効にしている場合、 PoP JWT はここで得た値を持っていなければ use_attestation_challenge で拒否されます。

無認証です

不透明な nonce を返すだけで、リクエストからは何も読みません。クライアント認証の前に呼ぶ必要があるため、認証は要求しません。

有効期限まで再利用できます

チャレンジは単回消費ではなく、期限まで何度でも使えます（Section 12.1 が挙げる 3つの方式のうちの1つ）。

レスポンスは Cache-Control: no-store を伴います（Section 6.3 の要求）。

既に持っているチャレンジが期限切れになった場合、このエンドポイントを呼ばなくても、エラー応答に付く OAuth-Client-Attestation-Challenge ヘッダから次の値を得られます。

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

Responses

Response samples

200
500

Content type

application/json

{"attestation_challenge": "string"
}

OIDCメタデータ

OpenID Connect Discovery 1.0 に基づく、OpenID Provider（OP）のメタデータ情報を提供するエンドポイント群です。

📘 関連仕様:
OpenID Connect Discovery 1.0

OpenID Connect Discovery

OpenID Connect Discovery 1.0 に基づく、OpenID Provider（OP）のメタデータ情報を提供するエンドポイント群です。

認可エンドポイント、トークンエンドポイント、UserInfoエンドポイント、JWKs URI など、 OpenID Connect の各種機能に必要な構成情報を機械可読形式（JSON）で提供します。

このメタデータは、クライアントがOPと連携するために事前に取得・検証するもので、クライアントの自動構成やセキュアな連携を実現する基盤となります。

📘 関連仕様: OpenID Connect Discovery 1.0

🔍 提供される主な情報：

issuer（発行者識別子）
authorization_endpoint
token_endpoint
userinfo_endpoint
jwks_uri（公開鍵取得用エンドポイント）
response_types_supported、grant_types_supported などの対応方式

Responses

Response samples

200
429
500
503
504

Content type

application/json

{"issuer": "string",
"authorization_endpoint": "string",
"token_endpoint": "string",
"userinfo_endpoint": "string",
"jwks_uri": "string",
"registration_endpoint": "string",
"scopes_supported": ["string"
],
"response_types_supported": ["string"
],
"response_modes_supported": ["string"
],
"grant_types_supported": ["string"
],
"acr_values_supported": ["string"
],
"subject_types_supported": ["string"
],
"id_token_signing_alg_values_supported": ["string"
],
"id_token_encryption_alg_values_supported": ["string"
],
"id_token_encryption_enc_values_supported": ["string"
],
"userinfo_signing_alg_values_supported": ["string"
],
"userinfo_encryption_alg_values_supported": ["string"
],
"userinfo_encryption_enc_values_supported": ["string"
],
"request_object_signing_alg_values_supported": ["string"
],
"request_object_encryption_alg_values_supported": ["string"
],
"request_object_encryption_enc_values_supported": ["string"
],
"token_endpoint_auth_methods_supported": ["string"
],
"token_endpoint_auth_signing_alg_values_supported": ["string"
],
"display_values_supported": ["string"
],
"claim_types_supported": ["string"
],
"claims_supported": ["string"
],
"service_documentation": "http://example.com",
"claims_locales_supported": ["string"
],
"ui_locales_supported": ["string"
],
"claims_parameter_supported": true,
"request_parameter_supported": true,
"request_uri_parameter_supported": true,
"require_request_uri_registration": true,
"op_policy_uri": "http://example.com",
"op_tos_uri": "http://example.com"
}

JSON Web Key Set (JWKS)

トークンの署名を検証するための公開鍵セット（JWK Set）を返します。

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

Responses

Response samples

200
429
500
503
504

Content type

application/json

{"keys": [{"kty": "EC",
"kid": "ssf-debug",
"use": "sig",
"alg": "ES256",
"crv": "P-256",
"x": "nitxvSyqpZEhGXT-oJ8CJD_Pr3feMVFAO43d8TlHk1w",
"y": "xA6Slvr4rRnF53TNaIdeRsw9v655xGlHPD3YNGy_CMY"
}
]
}

SSF

Shared Signals Framework (SSF) は、OpenID Foundation により策定されたセキュリティイベント共有の標準仕様です。 IdP-Server では、Push Delivery Mode に対応しており、SET（Security Event Token）形式の通知を POST リクエストで受信します。

RFC 8935 に準拠し、セッション失効、アカウント停止、クレデンシャル変更などの重要イベントを連携できます。

📘 仕様: RFC 8935 - Push-Based Event Delivery

SSF (Shared Signals Framework) Push Notification Receiver ※ idp-serverからイベントを受信するアプリが作成するAPI仕様です。任意のパスを指定できます。

このエンドポイントは、OpenID Shared Signals Framework (SSF) における Push型通知 (Push Delivery Mode) を受信するためのものです。

📘 仕様準拠: RFC 8935

🔐 利用されるイベント例（例: RISC仕様準拠）:

https://schemas.openid.net/secevent/risc/event-type/account-disabled
https://schemas.openid.net/secevent/risc/event-type/credential-change-required
https://schemas.openid.net/secevent/risc/event-type/sessions-revoked

このエンドポイントは、ベースとなるSecurity Event Token (SET) 形式のJWTを受け入れ、必要に応じて検証・処理を行うものです。

🔒 認証には POST リクエストの Authorization ヘッダーを使用することが推奨されます（例: Bearer Token）。

Request Body schema: application/secevent+jwt
required

string (SecurityEventToken)

Security Event Token (SET) は RFC 8417 に準拠した JWT 形式のセキュリティイベントメッセージです。 application/secevent+jwt の POST リクエストボディとして送信されます。

SET の構成

JWTのPayload部は以下のClaimを含む必要があります（RFC 8417）：

iss (Issuer): 発行者の識別子（例: https://idp.example.com）
aud (Audience): 対象となる受信者の識別子（例: https://relying-party.example.org）
iat (Issued At): 発行時刻（Unix時間）
jti (JWT ID): トークンの一意な識別子（リプレイ防止）
events: セキュリティイベントのオブジェクト。キーはイベントタイプのURI。

例: Account Disabled イベント

{
  "iss": "https://idp.example.com",
  "aud": "https://relying-party.example.org",
  "iat": 1682509200,
  "jti": "4f1g23a12aa",
  "events": {
    "https://schemas.openid.net/secevent/risc/event-type/account-disabled": {
      "subject": {
        "sub": "248289761001"
      }
    }
  }
}

JWT全体は署名される必要があります（通常はRS256など）。ヘッダー: {"alg": "RS256", "typ": "secevent+jwt"}

詳細は RFC 8417 を参照。

Responses

Response samples

429
500
503
504

Content type

application/json

Example

スロットリング（秒間リクエスト制限）

{"message": "Too Many Requests"
}

SSF Discovery Configuration

Shared Signals Framework (SSF) の Discovery 情報を提供します。

SSF 1.0 仕様に基づき、受信者（Receiver）が送信者（Transmitter）から SSF 関連のメタデータ情報を取得するために使用されます。

このエンドポイントは RFC 8935 および SSF Discovery の仕様に準拠し、 Push-Based Delivery に関する設定情報を提供します。

テナント識別方式:

パス形式: /{tenant-id}/.well-known/ssf-configuration
クエリ形式: /.well-known/ssf-configuration/{tenant-id}

📘 関連仕様:

Responses

Response samples

200
429
500
503
504

Content type

application/json

{"issuer": "https://idp-server.example.com",
"jwks_uri": "https://idp-server.example.com/v1/ssf/jwks",
"delivery_methods_supported": ["https://schemas.openid.net/secevent/risc/delivery-method/push"
],
"configuration_endpoint": "https://idp-server.example.com/.well-known/ssf-configuration",
"status_endpoint": "https://idp-server.example.com/v1/ssf/status",
"add_subject_endpoint": "https://idp-server.example.com/v1/ssf/add-subject",
"remove_subject_endpoint": "https://idp-server.example.com/v1/ssf/remove-subject",
"verification_endpoint": "https://idp-server.example.com/v1/ssf/verification",
"critical_subject_members": ["sub",
"email"
]
}

JSON Web Key Set (JWKS)

SETの署名を検証するための公開鍵セット（JWK Set）を返します。

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

Responses

Response samples

200
429
500
503
504

Content type

application/json

{"keys": [{"kty": "EC",
"kid": "ssf-debug",
"use": "sig",
"alg": "ES256",
"crv": "P-256",
"x": "nitxvSyqpZEhGXT-oJ8CJD_Pr3feMVFAO43d8TlHk1w",
"y": "xA6Slvr4rRnF53TNaIdeRsw9v655xGlHPD3YNGy_CMY"
}
]
}

外部アカウント連携

idp-server 独自の拡張。認証済みユーザーが外部IdPのアカウントを追加で紐付け、外部IdPが発行したトークンを idp-server に保管します。

ここにあるのは、ブラウザがトップレベルで開く 2 本（/v1/linking/start・/v1/linking/callback/{provider}）と、クライアントが保管トークンを取り出すエンドポイントです。連携の開始・確定・一覧・解除（/v1/me/linked-external-accounts）はリソースオーナー用API にあります。

📘 外部IdPアカウント連携

外部アカウント連携のブラウザ遷移（開始）

連携開始（POST /v1/me/linked-external-accounts/link/{provider}）が返した start_url です。 RP はブラウザをトップレベル遷移でここへ送ります（iframe の中では成立しません）。

idp-server のブラウザセッションから操作者を解決し、連携を開始したユーザーと一致するかを照合します。ブラウザセッションとして使うのは、ログインで発行した __Host-IDP_BROWSER_{tenant-id} Cookie が OP セッションと合うときだけです。合わなければセッションが無いのと同じに扱います。一致すれば、ブラウザ束縛の Cookie（__Host-IDP_LINK_BINDING_{tenant-id}、Secure・Path=/・SameSite=Lax）を発行し、外部IdPの認可エンドポイントへ 302 で送ります。

Bearer は不要です。JSON は返さず、成功も失敗も 302 で答えます。

送り先

状況	`Location`
操作者が一致した	外部IdPの認可URL（`state`・`nonce`・`code_challenge`（`S256`）付き）
ブラウザセッションが無い、ログインが `linking_max_auth_age` より古い、またはログインの acr がクライアントの `linking_acr_values` に当たらない（連携セッションは有効）	このサーバーの認可エンドポイント（`prompt=login`・`login_hint=sub:<連携を始めたユーザー>`、`linking_acr_values` があれば `acr_values`）。ログインが終わると認可コードを発行せずに `/linking/start?state=...&returned_from_sign_in=true` へ戻る（ログインを取り消した場合も同じ）
ログインから戻ってもブラウザセッションが無い、ログインを取り消した、または acr が `linking_acr_values` に当たらない	`{redirect_uri}?linking=failed&error=login_required`（`state` は付けない）
ブラウザセッションが無く、連携セッションが無い・期限切れ・開始済み	テナントのエラー画面（`error=invalid_request`）
操作者が一致しない	テナントのエラー画面（`error=access_denied`）
連携セッションが無い・期限切れ・開始済み	テナントのエラー画面（`error=invalid_request`）
その他のエラー	テナントのエラー画面（`error=server_error`）

ブラウザセッションが無い場合、連携セッションは消さずに残すので、サインインしたブラウザから同じ start_url で続けられます。

テナントのエラー画面は {ui_config.base_url}/error/?error=...&error_description=...&tenant_id=... です（ui_config.base_url が無い場合はテナントのドメイン）。error_description は失敗の種類ごとの固定文です。

セキュリティイベント

external_account_link_failed（ブラウザセッションが無いだけの場合は記録しません）

path Parameters

tenant-id

required

string <uuid>

Example: 67e7eae6-62b0-4500-9eff-87459f63fc66

テナント識別子（UUID形式）

query Parameters

state

required

string

連携開始レスポンスの state。

クエリ自体が無い場合はリクエストパラメータの欠落として共通のエラーハンドラが処理し、 302 ではなく 500 の JSON（server_error）が返ります。

returned_from_sign_in

string

Value: "true"

idp-server が送り出したログインし直しから戻るときに、idp-server が付ける（ログインを取り消した場合も付く）。認証の結果は表さない。これが true で、まだブラウザセッションが無い（または古い）ときは、もう一度ログインへは送らずに login_required を返す。RP が付ける必要はない。

Responses

Response samples

500

Content type

application/json

{"message": "Internal server error"
}

外部アカウント連携のブラウザ遷移（コールバック）

外部IdPが認可応答を返す先です。連携先設定（federation-configurations）の redirect_uri にこの URL を登録します。

state から連携セッションを引き、/v1/linking/start を通ったブラウザか（__Host-IDP_LINK_BINDING_{tenant-id} Cookie）を認可コードを交換する前に照合します。同じ名前の Cookie が 2 つ以上届いたときは照合に失敗します。照合できたら認可コードを交換し（PKCE）、ID Token の検証・userinfo の取得を経て、トークンを暗号化して連携セッションに預けます。 連携はまだ確定しません。 RP が戻り先で受け取った state で POST /v1/me/linked-external-accounts/complete を呼んで確定します。

Bearer は不要です。JSON は返さず、成功も失敗も 302 で答えます。GET のみで、外部IdPの response_mode=form_post には対応していません。ブラウザ束縛の Cookie は結果に関わらず削除します。

送り先

状況	`Location`
トークンを預けた	`{redirect_uri}?linking=done&state=...`
外部IdPが `error` を返した	`{redirect_uri}?linking=failed&error=...&state=...`
`code` も `error` も無い	`{redirect_uri}?linking=failed&error=server_error&state=...`
トークン交換・ID Token の検証・userinfo の失敗、その他の想定外のエラー	`{redirect_uri}?linking=failed&error=server_error&state=...`
`state` が無い・未知	テナントのエラー画面（`error=invalid_request`）
連携セッションが期限切れ・コールバックを待つ状態でない（再読み込み・戻るボタン・二重送信）	テナントのエラー画面（`error=invalid_request`）
ブラウザ束縛が無い・一致しない	テナントのエラー画面（`error=access_denied`）

戻り先へ返す error は access_denied / temporarily_unavailable / server_error のどれかです。外部IdPが付けてきた error は access_denied と temporarily_unavailable だけをそのまま使い、それ以外は server_error にします。 error_description と外部IdPの応答本文は返しません。

戻り先へ失敗を返したときは連携セッションを削除します。エラー画面へ送るときは、連携セッションに触れません。

戻り先（redirect_uri）は連携開始のときにクライアントの linking_return_uris と完全一致で照合済みです。テナントのエラー画面の形は /v1/linking/start と同じです。

セキュリティイベント

external_account_link_failed

path Parameters

tenant-id required	string <uuid> Example: 67e7eae6-62b0-4500-9eff-87459f63fc66 テナント識別子（UUID形式）
provider required	string Example: example-idp 連携先の設定名（`sso_provider`）。連携先設定の `redirect_uri` と合わせるためのもので、処理には `state` から引いた連携セッションの連携先を使います。

query Parameters

code	string 外部IdPが発行した認可コード
state	string 外部IdPへ送った `state`（連携セッションの識別子）
error	string 外部IdPが返したエラーコード
error_description	string 外部IdPが返したエラーの説明。戻り先には渡しません

Responses

Response samples

500

Content type

application/json

{"message": "Internal server error"
}

保管トークンの取得

連携したアカウントの外部IdPアクセストークンを、クライアントがユーザーに代わって取り出します。ユーザーは token（そのユーザーのアクセストークン）で指定します。Authorization ヘッダーはクライアント認証が使うため、Bearer では送りません。

次の全てを満たす場合だけトークンを返します。

クライアントが認証に成功している。public クライアント（none）は拒否します。attest_jwt_client_auth（ABCA）は使えます
token が有効なユーザーのアクセストークン（client_credentials で発行されたものでない）で、認証したクライアントと同じクライアントに発行され、linked_account:read_token スコープを持つ
token が sender-constrained なら、その送り手から出されている（DPoP は DPoP ヘッダーの proof、mTLS は同じクライアント証明書、クライアントインスタンス束縛はこのリクエストのクライアント認証で使われたインスタンスの鍵）
ユーザーが有効である
alias がそのユーザーの連携にある
連携先がクライアントの extension.linking_token_providers に含まれている

返すのはアクセストークンだけで、リフレッシュトークンは返しません。アクセストークンの期限まで 30 秒を切っていれば、保管しているリフレッシュトークンで更新してから返します。同じ連携への同時リクエストは行ロックで待ち合わせ、リフレッシュトークンを二重に使いません。

クライアント認証

トークンイントロスペクションと同じ方式でクライアントを認証します（client_secret_basic / client_secret_post / client_secret_jwt / private_key_jwt / tls_client_auth / self_signed_tls_client_auth / attest_jwt_client_auth）。クライアントは Authorization の Basic、client_id、Client Attestation の sub の順で特定します。

クライアント認証の失敗は、方式に関わらず 401 invalid_client にまとめて返します。 attest_jwt_client_auth 固有のエラーコードと WWW-Authenticate / OAuth-Client-Attestation-Challenge ヘッダーは返しません。

セキュリティイベント

external_account_token_retrieved / external_account_token_retrieval_failed
external_account_token_refreshed（リフレッシュしたとき）
external_account_relink_required（relink_required のとき）

path Parameters

tenant-id required	string <uuid> Example: 67e7eae6-62b0-4500-9eff-87459f63fc66 テナント識別子（UUID形式）
alias required	string Example: example-idp-k3f9x2qa 連携の識別子（連携一覧の `alias`）

header Parameters

Authorization	string Basic認証ヘッダー（client_secret_basic認証方式用）。 `Basic base64(client_id:client_secret)` 形式で送信します。
OAuth-Client-Attestation	string <jwt> Client Attestation JWT（`attest_jwt_client_auth` 用）。 Client Attester が発行した JWT で、`cnf.jwk` にクライアントインスタンスの公開鍵を持ちます。 `OAuth-Client-Attestation-PoP` と必ず対で送信します（片方だけのリクエストは拒否されます）。 `typ` は `oauth-client-attestation+jwt`。
OAuth-Client-Attestation-PoP	string <jwt> Client Attestation PoP JWT（`attest_jwt_client_auth` 用）。 `OAuth-Client-Attestation` の `cnf.jwk` に対応する秘密鍵で署名し、そのインスタンスが鍵を保持していることを示します。`typ` は `oauth-client-attestation-pop+jwt`。テナントが `client_attestation_challenge_required` を有効にしている場合、 `challenge` クレームにチャレンジエンドポイントで得た値が必要です。

Request Body schema: application/x-www-form-urlencoded
required

token required	string トークンを取り出すユーザーのアクセストークン。`linked_account:read_token` スコープを持ち、このリクエストで認証するクライアントに発行されたものに限ります。
client_id	string クライアント識別子。client_secret_post認証やmTLS認証で使用します。 client_secret_basic認証の場合はAuthorizationヘッダで送信されるため省略可能。
client_secret	string クライアントシークレット。client_secret_post認証でのみ使用します。 client_secret_basic認証の場合はAuthorizationヘッダで送信されます。
client_assertion_type	string Value: "urn:ietf:params:oauth:client-assertion-type:jwt-bearer" JWT認証（client_secret_jwt / private_key_jwt）で使用するアサーションタイプ。固定値: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion	string JWT認証で使用する署名済みJWTアサーション。 client_secret_jwt: client_secretで署名 private_key_jwt: 登録済み秘密鍵で署名

Responses

Response samples

Content type

application/json

{"access_token": "ya29.a0Af...",
"token_type": "Bearer",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
"expires_in": 3599,
"scope": "openid email offline_access"
}

idp-server API (1.0.0)

CIBAフロー

バックチャンネル認証リクエスト

path Parameters

header Parameters

Request Body schema: application/x-www-form-urlencodedrequired

login_hint

Responses

Response samples

認可コードフロー

Pushed Authorization Request (PAR)

クライアント認証

path Parameters

header Parameters

Request Body schema: application/x-www-form-urlencodedrequired

login_hint

Responses

Request samples

Response samples

認可リクエスト

query Parameters

login_hint

verified_claims（身元確認済みクレーム / OIDC4IDA）

Responses

Response samples

認可リクエスト（POST）

仕様準拠

POSTメソッドの利点

パラメータ

参考

Request Body schema: application/x-www-form-urlencodedrequired

Responses

Response samples

トークン

トークンリクエスト

path Parameters

header Parameters

Request Body schema: application/x-www-form-urlencodedrequired

Responses

Response samples

トークン検証

クライアント認証

path Parameters

header Parameters

Request Body schema: application/x-www-form-urlencodedrequired

Responses

Response samples

トークン検証（拡張）

RS forwarding pattern（重要）

エラーハンドリング

クライアント認証

path Parameters

header Parameters

Request Body schema: application/x-www-form-urlencodedrequired

Responses

Response samples

トークン失効

クライアント認証

path Parameters

header Parameters

Request Body schema: application/x-www-form-urlencodedrequired

Responses

Response samples

OIDC

ユーザーInfo

Authorizations:

Responses

Response samples

ユーザーInfo

Authorizations:

Responses

Response samples

RP-Initiated Logout エンドポイント

path Parameters

query Parameters

Responses

Response samples

Client Attestation

Client Attestation チャレンジの発行

無認証です

Request Body schema: application/x-www-form-urlencoded
required

Request Body schema: application/x-www-form-urlencoded
required

Request Body schema: application/x-www-form-urlencoded
required

Request Body schema: application/x-www-form-urlencoded
required

Request Body schema: application/x-www-form-urlencoded
required

Request Body schema: application/x-www-form-urlencoded
required

Request Body schema: application/x-www-form-urlencoded
required

Request Body schema: application/secevent+jwt
required

Request Body schema: application/x-www-form-urlencoded
required