IHV like なユースケースへのOpenID Connect 関連仕様の適用事例

2026/08/25 開催「OAuth/OIDC Numa (Immersion) Workshop 2026」でのオプティム 菊池の発表資料です。

Transcript

1. IHV like なユースケースへの OpenID Connect 関連仕様の適用事例 株式会社オプティム 菊池 佑 2026/08/25 © 2019-2026 OPTiM Corp. All rights reserved.
2. About me Yuu Kikuchi / 菊池 佑 * 株式会社オプティム * Executive Engineer * Product: OPTiM ID/ID+, OPTiM AIR and around services * OpenID Foundation Japan * 参加WG: * TG40 WG SWG leader * 人材育成推進WG 技術SWG leader (Ph3) * KYC WG (Ph1 -) © 2019-2026 OPTiM Corp. All rights reserved. 2
3. 今日話すこと 弊社オプティムのサービス「自治体公式スーパーアプリ」で IHV モデル (Issuer-Holder-Verifier) に近いユースケースの機能を OpenID Connect / OAuth ベースで設計した事例について 標準仕様の適用範囲や課題の共有 © 2019-2026 OPTiM Corp. All rights reserved. 4
4. 「自治体公式スーパーアプリ」 自治体ごとの各メディアを統合するプラットフォームサービス 全国の複数自治体に提供中 © 2019-2026 OPTiM Corp. All rights reserved. 5
5. 「デジタル市民証」機能 提供自治体の「市民」であることを証明する機能 マイナンバーカードから取得した本人情報を オンライン・オフラインで提示することで、住民限定の施策に活用可能 みらい ID 市民証 マイナンバーカードを 用いた本人認証 利用者ID（メールアドレス） 利用者ID（メールアドレス） 名前（自己申告） 名前（自己申告情報） 氏名、住所、生年月日、性別 （本人確認済み情報） © 2019-2026 OPTiM Corp. All rights reserved. 6
6. フェデレーションモデルの採用に至った経緯  以下の理由から、 VC 関連技術の利用は難しいと判断 ◼ 最先端技術であり、標準仕様策定も当時は道半ば（※ 市民証機能は 2023 年秋に初版リリース） ◼ 目的に対して VC の技術要素が複雑であり、開発スケジュールとのバランス取りが困難 ◼ クレデンシャルのライフサイクルの問題について、同期パスキー以前の FIDO2 と似たような課題感  元々「自治体公式スーパーアプリ」は OpenID Connect の認証基盤を備えていた ◼ スーパーアプリ上のミニアプリ群は、OIDC を利用したシングルサインオンを実装済み VC 関連技術を新たに導入するよりも、OIDC4IDA の属性連携の考え方を組み合わせる方が 既存アーキテクチャとの親和性が高いと考えた © 2019-2026 OPTiM Corp. All rights reserved. 8
7. 実現手法 マイナンバーカードを利用した本人確認を実施し、 デジタル市民証を発行 本人確認（身元確認） JPKI 署名用電子証明書方式 または 容貌確認方式（書類画像型） © 2019-2026 OPTiM Corp. All rights reserved. 10
8. 実現手法 デジタル市民証の市民情報を、API 経由で取得（OAuth のリソースサーバーとして実装） 市民 担当者 （オンラインの場合） 市民証情報を取得 （対面の場合） デジタル市民証 QR コードを提示・読取 QR コードからアクセストークンを取得 市民証情報を取得 © 2019-2026 OPTiM Corp. All rights reserved. 11
9. 実現手法（オフライン）  市民：QRコード表示 ◼ スーパーアプリ自身のアクセストークンを利用して、QR Code Token を発行 ◼ 発行された QR Code Token を QR コード形式で画面表示  担当者：QR コード読み取り（準備） ◼ 事前に担当者として、読み取りアプリにログイン ◼ 市民の提示した QR コードから、QR Code Token を取得 ◼ 読み取った QR Code Token を利用し、市民文脈のアクセ ストークンに引き換え ◼ 引き換えたアクセストークンを利用し、本人確認済み属性 取得 API を実行 © 2019-2026 OPTiM Corp. All rights reserved. 12
10. 標準仕様をどう適用したか OIDC / OIDC4IDA の考え方と表現方法を適用し、要件を実現  OpenID Connect / OAuth 2.0 ◼ Authorization Code Flow で市民・担当者を認証・API 認可  OpenID Connect for Identity Assurance (OIDC4IDA) ◼ 本人確認済み属性を QR コード経由で取得するための scope を定義 ◼ Userinfo Endpoint による属性返却の考え方を適用し、独自の OAuth Resource Server API として実装  OpenID Identity Assurance Schema Definition ◼ 属性の検証方法のスキーマ表現（一部） ⚫ trust_framework, time, evidences[*] claims  OpenID Connect for Identity Assurance Claims Registration ◼ 本人確認済み属性のクレーム表現（利用しているのは OIDC Core の範囲のみ） ⚫ name, birthdate, gender, address claims © 2019-2026 OPTiM Corp. All rights reserved. 13
11. 既存仕様では足りなかったところ  QR Code Token の発行 ◼ 属性保有者（市民）を介して、第三者（担当者）に属性を取得させるための認可フローが、既存仕様では要件を満たせなかった ◼ OAuth 2.0 Device Authorization Grant (RFC 8628) ⚫ 制約付きデバイス向けのフロー ⚫ アクセストークンを必要とするデバイスを利用している本人が、別のデバイスで認可することを想定 ⚫ デバイス = アクセストークンが必要な側が QR コード表示を行うため、用途が噛み合わない ◼ OpenID Connect Client-Initiated Backchannel Authentication Flow (CIBA) ⚫ サービスの利用端末と認証を行う端末を分離するフロー ⚫ 認証する側のユーザーが Authentication Device で承認するモデルであり、今回の「属性保有者がQRを提示し、第三者が読み取る」役割関係とは噛み合わ なかった  本人確認済み属性の返却 API ◼ OIDC4IDA とは異なり、通常の OAuth Resource Server として設計することになった ⚫ OIDC4IDA では、あくまで自身のクレームを RP に提供することが前提のため、ID Token または Userinfo Endpoint を利用して返却する仕様 ⚫ 今回は、第三者に対して属性保有者の属性を返却するため、Userinfo Endpoint では対応できなかった © 2019-2026 OPTiM Corp. All rights reserved. 14
12. フェデレーション (OIDC) ベースで良かったこと・課題  RP となるアプリの開発を、一般的なアプリ開発知識だけで実現できた ◼ アプリは元々 OIDC RP を実装済みのため、OAuth 2.0 の Resource Server に対して API 呼び出しをするだけで良い ◼ VC 系の技術を使う場合、新しく覚えなければいけない技術が多数あった ⚫ トランスポート層として、ISO/IEC 18013-5 (mdoc /mDL) や OpenID4VP、Digital Credentials API など ⚫ クレデンシャルフォーマットとして、SD-JWT や mdoc など  一般人に馴染みのある UX で機能を実現できた ◼ そもそも OpenID for VP の場合、Verifier が QR コードを提示する ◼ 属性提示側が QR コードを提示する方が、UX として馴染みがあるため、リテラシーを問わず利用しやすい  属性のライフサイクル管理やマルチデバイス管理が楽（サーバー側で制御できる） ◼ 転居や冠婚葬祭などのライフサイクルイベントに応じて、市民証を失効・一時停止する可能性がある ⚫ 最新の利用者情報（4情報）提供サービスが利用 ◼ マルチデバイスでの利用も、スーパーアプリへのログインのみで対応可能  完全オフライン（通信なし）ケースには対応できていない ◼ 自治体ユースケースであることから、災害時の通信輻輳・断絶などを考慮すると、ローカルから属性を提示する方法も必要 © 2019-2026 OPTiM Corp. All rights reserved. 15
13. takeaways  この実装を通して学んだこと ◼ 新しい技術や考え方に囚われず、普及している既存技術やエコシステムを再活用する選択肢 ◼ 部分的な適用・再利用できる標準仕様の設計の美しさと価値 OpenID Connect / OAuth 2.0 関連仕様の設計思想を、もっと好きになった  悩んでいること ◼ 今回と同様の課題を持つユースケースは、他にも存在するのか ◼ 今回のように独自拡張で対応する場合、標準化への再還元はどのような基準で考えるべきか ◼ IHV モデルとフェデレーションモデルは、どう使い分けるのがよいのか 同じような悩みをお持ちの方、いませんか？ © 2019-2026 OPTiM Corp. All rights reserved. 16
14. © 2019-2026 OPTiM Corp. All rights reserved.