Skip to content

MS_OIDCSelfIssuedOP

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

OpenID Connect - Self-Issued OP

概要

Final を参照して記述。

補足（「自己発行」の意味）: 通常の OpenID Connect では
サーバ側の OP が ID トークンを発行するが、SIOP では
利用者の端末上のアプリが自分で OP になって
ID トークンを発行し、自分の鍵で署名する。
中央の IdP を介さずに「この端末（この鍵の持ち主）である」ことを
主張できるのが特徴で、
後年の 分散型 ID（DID）／Verifiable Credentials の
出発点にもなった考え方である。

詳細

SIOP

SIOPの機能

OpenID Connect Self-issued OP（SIOP）は、
端末上で動作して、ID トークンを発行することで、

  • SIOP が動作する端末自体の識別（端末認証）
  • 安全な端末情報の受け渡し（改ざんを検出可能）。

を実現する機能を提供すると言える。

SIOPのDiscovery

以下の Dynamic Discovery を得たかのように振る舞う。

{
 "authorization_endpoint":
   "openid:",
 "issuer":
   "https://self-issued.me",
 "scopes_supported":
   ["openid", "profile", "email", "address", "phone"],
 "response_types_supported":
   ["id_token"],
 "subject_types_supported":
   ["pairwise"],
 "id_token_signing_alg_values_supported":
   ["RS256"],
 "request_object_signing_alg_values_supported":
   ["none", "RS256"]
}

※ Discovery Process で入力された識別子が self-issued.me ドメインを含んでいた場合。

（OpenID Connect - Discoveryを参照）

SIOPのRegistration

以下の Client Registration Response を得たかのように振る舞う。

  • client_id: Client の redirect_uri 値。
  • client_secret_expires_at : 0

（OpenID Connect - Dynamic Client Registrationを参照）

補足（実体のない Discovery / Registration）: SIOP には
問い合わせるサーバが存在しないため、
**Discovery も Registration も「そう返ってきたことにする」**という
決め打ちの定義になっている。
これにより、RP 側は通常の OpenID Connect と同じコードのまま
SIOP を扱える。

認可リクエスト & レスポンス

認可リクエストの例

以下の Redirect レスポンスから認可リクエスト。

  • Authorization Endpoint
    カスタム URL スキーム（openid://）

  • パラメタ

    • REQUIRED

      • scope="* openid *"
      • response_type="id_token"
      • client_id は redirect_uri の値

    • OPTIONAL

      • claims
      • request
      • registration ★
      • id_token_hint ★
      • 他のパラメータも送ってもよい
HTTP/1.1 302 Found
Location: openid://?
  response_type=id_token
  &client_id=https%3A%2F%2Fclient.example.org%2Fcb
  &scope=openid%20profile
  &state=af0ifjsldkj
  &nonce=n-0S6_WzA2Mj
  &registration=%7B%22logo_uri%22%3A%22https%3A%2F%2Fclient.example.org%2Flogo.png%22%7D

※ 全体 URL 長は ASCII で 2048 文字を超えてはならない (MUST NOT)。

移行メモ（★ の意味）: 元ページで registration と id_token_hint に
付けられていた「★」は、SIOP 固有（通常の OP には無い）のパラメタである
ことを示す印と読める（凡例は元ページに無い）。
registration は RP が自分の情報（表示名やロゴ）を
その場で渡すためのもの、id_token_hint は
既に発行済みの ID トークンを提示して再認証を求めるためのものである。

認可レスポンスの例

通常の Implicit Flow と同じ。

IDトークン

（OpenID Connect - IDトークンを参照）

通常のIDトークンとの差異

通常の Implicit Flow との差異

  • iss
    「https://self-issued.me」固定

  • sub
    sub_jwk の公開鍵の拇印の Base64url エンコード（JWK Thumbprint 参照）

  • sub_jwk

補足（sub が鍵の拇印である意味）: 通常の OP では sub は
OP が採番したユーザ ID だが、SIOP では
鍵そのものから導出される。
つまり「鍵を持っていること」＝「その識別子の持ち主であること」であり、
鍵を作り直すと別人になる。
後述の Recruit ID の例で
「sub ＝ 証明書の拇印をアカウントと紐付ける」としているのは、
この性質を利用して端末（鍵）を利用者に結びつける運用である。

IDトークンの例

{
 "iss": "https://self-issued.me",
 "sub": "wBy8QvHbPzUnL0x63h13QqvUYcOur1X0cbQpPVRqX5k",
 "aud": "https://client.example.org/cb",
 "nonce": "n-0S6_WzA2Mj",
 "exp": 1311281970,
 "iat": 1311280970,
 "sub_jwk": {
   "kty":"RSA",
   "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
   4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
   tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
   QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
   SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
   w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
   "e":"AQAB"
  }
}

応用

この仕組みをどう応用していくか？がポイントになる。

Recruit ID

OAuth PKCE と併用
（というより OAuth PKCE で SIOP を併用して強化するイメージ）

  • Recruit ID は、OP（IdP/STS）だが、Self-Issued OP（オプション）を使う時には RP になる。

  • Public Client で認証する際に、Client Credential を持てない Public Client 自体の認証が可能。
    （sub = 証明書の拇印の値を Recruit ID のアカウントと紐付ける）

  • なお、秘密鍵は、Shared KeyChain（iOS の証明書ストアらしい）で管理する。

補足（Public Client の弱点を補う）: OAuth PKCE は
「認可コードの横取り」は防げるが、
クライアント自身が本物かどうかまでは保証しない
（Public Client は client_secret を持てないため）。
SIOP の ID トークンを併用すると、
端末内の鍵で「同じアプリ・同じ端末である」ことを示せるので、
ここを補える——というのがこの応用例の趣旨である。

その後の展開

補足（SIOP v2 と Verifiable Credentials）: 本ページが扱う SIOP は
OpenID Connect Core の一節（7. Self-Issued OpenID Provider）だが、
その後 SIOP v2 として独立した仕様に整理され、
**OpenID for Verifiable Presentations（OID4VP）**と組み合わせて
デジタル ID ウォレットの基盤仕様になっている。
https://self-issued.me という iss の固定値も
SIOP v2 では https://self-issued.me/v2 に変わっている。

移行メモ（補完）: 元ページは応用の 2 つ目が「・・・」のみで
書かれていなかったため、その後の仕様の展開を補った。
著者による本文が加筆された場合は置き換えること。

参考

Qiita

本 Wiki 内

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

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally