メインコンテンツまでスキップ
API docs by Redocly

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認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。

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) 形式で送信します。

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認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。

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) 形式で送信します。

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

Content type
application/x-www-form-urlencoded
Example
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 を参照。

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

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メソッドの利点

  1. URLの長さ制限を回避: authorization_details や claims などの長いパラメータに対応
  2. セキュリティ向上: ブラウザ履歴やプロキシログにセンシティブなパラメータが残らない
  3. プライバシー保護: 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

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認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。

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) 形式で送信します。

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

Response samples

Content type
application/json
Example
{
  • "access_token": "string",
  • "token_type": "Bearer",
  • "expires_in": 3600,
  • "refresh_token": "string",
  • "id_token": "string",
  • "scope": "openid profile email",
  • "authorization_details": [
    ]
}

トークン検証

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

📘 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認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。

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) 形式で送信します。

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",
  • "property1": null,
  • "property2": null
}

トークン検証（拡張）

アクセストークンやリフレッシュトークンの状態を確認するための標準仕様を拡張したエンドポイントです。 リソースサーバー側で実施している許可している

  • スコープを含んでいるか
  • クライアント証明書がバインディングされているか

の検証も実施してトークンの有効性を確認することができます。

トークンが有効な場合は、標準仕様に沿ったレスポンスを返却します。

トークンが無効な場合は、エラーの原因を含めてレスポンスを返却します。

📘 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認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。

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) 形式で送信します。

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

相互TLS通信で取得したPEM形式のクライアント証明書。 証明書バインディングされているクライアント証明書のサムプリントと一致しているかを検証します。

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",
  • "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認証方式。証明書のフィンガープリントを事前登録することで認証が成立します。

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) 形式で送信します。

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
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

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": {
    },
  • "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

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": {
    },
  • "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攻撃防止）

処理フロー:

  1. リクエストパラメータの検証
  2. id_token_hint によるセッション特定（推奨）
  3. エンドユーザーのセッション終了
  4. 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."

  1. クライアント識別必須: client_id または id_token_hint でクライアントを識別できない場合、リダイレクトを実行しません
  2. 事前登録必須: クライアントに post_logout_redirect_uris が登録されていない場合、リダイレクトを実行しません
  3. 完全一致検証: 指定された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

Content type
application/json
Example
{
  • "error": "invalid_request",
  • "error_description": "post_logout_redirect_uri provided but client could not be identified"
}

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

Content type
application/json
{
  • "issuer": "string",
  • "authorization_endpoint": "string",
  • "token_endpoint": "string",
  • "userinfo_endpoint": "string",
  • "jwks_uri": "string",
  • "registration_endpoint": "string",
  • "scopes_supported": [
    ],
  • "response_types_supported": [
    ],
  • "response_modes_supported": [
    ],
  • "grant_types_supported": [
    ],
  • "acr_values_supported": [
    ],
  • "subject_types_supported": [
    ],
  • "id_token_signing_alg_values_supported": [
    ],
  • "id_token_encryption_alg_values_supported": [
    ],
  • "id_token_encryption_enc_values_supported": [
    ],
  • "userinfo_signing_alg_values_supported": [
    ],
  • "userinfo_encryption_alg_values_supported": [
    ],
  • "userinfo_encryption_enc_values_supported": [
    ],
  • "request_object_signing_alg_values_supported": [
    ],
  • "request_object_encryption_alg_values_supported": [
    ],
  • "request_object_encryption_enc_values_supported": [
    ],
  • "token_endpoint_auth_methods_supported": [
    ],
  • "token_endpoint_auth_signing_alg_values_supported": [
    ],
  • "display_values_supported": [
    ],
  • "claim_types_supported": [
    ],
  • "claims_supported": [
    ],
  • "service_documentation": "http://example.com",
  • "claims_locales_supported": [
    ],
  • "ui_locales_supported": [
    ],
  • "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

Content type
application/json
{
  • "keys": [
    ]
}

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

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

Content type
application/json
{}

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

Content type
application/json
{
  • "keys": [
    ]
}