OpenID Connectによるサービス間連携

JJUG CCC 2026 Spring

Transcript

1. OpenID Connectによる サービス間連携 JJUG CCC 2026 Spring / #jjug_ccc_c 2026年05月30日 Shigeki Shoji
2. 庄司重樹 熊本大学大学院 教授システム学専攻 博士前期課程 ICTインストラクター / アジャイルコーチ e-Learning Professional SCORM技術者 好きな言語：Scala、Java
3. 話さないこと • OpenID Connect以外のフェデレーション、SAML等 • OpenID Connectのフローは、認可コードフローとサードパー ティ開始ログインフロー以外 • SPAやモバイルアプリを対象とした実装 • ベストプラクティス、あるいは絶対的な解決策ではない 3
4. 認可と認証 • 『リソースに対してアクセス許可を与えることを、「アクセス 認可」と呼ぶ』(崎村 2021) • OAuth 2.0は、プリンシパル（リソース所有者）がアプリケーションに 対して、自身の保持するコンテンツへの制限付きアクセスを安全に許 可するためのフレームワーク。 • 認証はデジタル世界にアクセスしようとするユーザが本人であ ることを証明・検証するプロセス。 4
5. 構成 5
6. 認可 6
7. 最小権限の原則 "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." システムのすべてのプログラムおよびすべてのユーザーは、業務 を完了するために必要な、最小限の権限のセットを使用して動作 する必要がある。 引用： https://www.cs.cornell.edu/fbs/publications/leastPrivNeedham.pdf 7
8. IBAC (Identifier Based Access Control) • 識別子ごとにアクセス制御 例えば、ユーザ名でアクセス制御 識別子ごとに制御を行うため、識別子の数が多くなると保守が 煩雑 8
9. RBAC (Role Based Access Control) • ユーザの属性にロールを導入し、ロールによってアクセス制御 例えば、管理者ロールはすべてのリソースへのアクセスを許可 し、監査ロールは特定のリソースの読み取りアクセスを許可 ユーザの動的な性質に基づく制御が困難 9
10. ABAC (Attribute Based Access Control) • ポリシーの爆発的増加を防ぎ、スケール可能に 属性値を評価してアクセス許可 10
11. RBACとABACの比較 • プロダクト管理者はプロダクトに関連するすべてのリソースへ のアクセスが許可される。プロダクトはA〜Cの３個ある。 11 RBAC ABAC ProductA_Administrator Product_Administrator "Condition": { “StringEquals”: { "aws:ResourceTag/Product": "${aws:PrincipalTag/Product}” } } ProductB_Administrator ProductC_Administrator
12. AWSマネジメントコンソールの例 IAMポリシー 12
13. ロールにAdministratorを含む場合 13
14. ロールにAdministratorを含まない場合 14
15. ABACの実装に使用できるOSS • Open Policy Agent Rego言語を使用してポリシーを記述 15
16. OpenID Connect (OIDC) • OIDCは認証 認可リクエスト：アプリケーション (Client) が許可してほしい アクセスの内容 (openid、email、profile 等) を scope に指定 して取得 • openid が scope にある場合、id_token (JWT) を受け取ること ができる • id_tokenはあくまでも身元を証明するための「身分証明書」。 アクセス制御のための「通行許可証」として設計されていない 16
17. 認証 17
18. デジタルアイデンティティ • 現実世界は、関係性を深めるまでは匿名のまま対応が可能。デ ジタル世界は、関係性の有無に関わらずプリンシパルの同一性 を保証する必要があり、認証が必要になっている。 18
19. フェデレーション型 • アドホック・フェデレーション • ハブ&スポーク・フェデレーション • アイデンティティ連携ネットワーク 19
20. OIDCを使ったクラウドアクセス • AWS • IAMのIDプロバイダとIAMロールとでAWSリソースに対するアクセス 許可が可能 • IAMロールの認証情報からAWSマネジメントコンソールへのアクセスも可能なた め、自由度が高い • Azure • Microsoft Entra IDに依存している • サードバーティのIDを登録して、Azure Portalにアクセスする仕組みがある 20
21. CI/CDで使用するOIDC • CI/CDパイプライン上のトークン • GitHub Actions • GitHub APIでid_tokenの取得が可能 • GitLab CI/CD • 指定したAudience値でid_tokenを生成し環境変数に設定する • id_tokenを使用してリソースにアクセス • AWSやAzureの場合、IAMロールやEntra IDを通じてアクセス 21
22. トークン • オパークトークン • セッションID • 自己完結型トークン • JWT 22
23. id_token (JWT) • ヘッダ、ペイロード、署名で構成 • 各パートは、. (ドット) で区切られる • ヘッダ、ペイロードは、JSONをBase64エンコードした文字列 • 署名は、ヘッダで指定されたアルゴリズム (alg) で署名し、そ れをBase64エンコードした文字列 23
24. サンプル ヘッダ： { "kid": "+XmXtOKuo9H+8XTZve0e8EbYN+MuYRGAxR6xXbErZxM=", "alg": "RS256" } 24
25. サンプル ペイロード（一部省略）： { "sub": "97149a88-40c1-707f-cc7b-c90ff631ee05", "iss": "https://cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-1_gRg8qgDYf", "aud": "5tufr8vhh79bp9nppbs8fouikv", "exp": 1779615184, "iat": 1779611585, "email": takesection@gmail.com } 25
26. 認可コードフロー 26
27. プロバイダ別のエンドポイント • Amazon Cognito Userpools 27 エンドポイント 認可エンドポイント https://[ドメインプレフィックス].auth.[リージョ ン].amazoncognito.com/oauth2/authorize トークンエンドポイント https://[ドメインプレフィックス].auth.[リージョ ン].amazoncognito.com/oauth2/token 公開鍵取得エンドポイント https://cognito-idp.[リージョン].amazonaws.com/[ドメインプレ フィックス]/.well-known/jwks.json
28. プロバイダ別のエンドポイント • Google 28 認可エンドポイント https://accounts.google.com/o/oauth2/v2/auth トークンエンドポイント https://oauth2.googleapis.com/token 公開鍵取得エンドポイント https://www.googleapis.com/oauth2/v3/certs
29. プロバイダ別のエンドポイント • Microsoft Entra ID (common) 29 エンドポイント 認可エンドポイント https://login.microsoftonline.com/common/oauth2/v2.0/authorize トークンエンドポイント https://login.microsoftonline.com/common/oauth2/v2.0/token 公開鍵取得エンドポイント https://login.microsoftonline.com/common/discovery/v2.0/keys
30. シークレット情報の管理 • CLIENT_SECRET System Managerのパラメータストアに暗号化して保存 30
31. 署名検証に使用するキー情報 公開鍵取得エンドポイントから取得可能 31 キー 説明 kid 鍵の識別子 alg 署名アルゴリズム（RSA SHA-256 の場合は RS256) use デジタル署名の検証の場合は “sig” n RSA公開鍵を構成する数学的なパラメータ（モジュラス） e RSA公開鍵を構成する数学的なパラメータ（指数）
32. 公開鍵情報のサンプル { "keys":[ { "alg":"RS256", "e":"AQAB", "kid":"+XmXtOKuo9H+8XTZve0e8EbYN+MuYRGAxR6xXbErZxM=", "kty":"RSA", "n":"0B-ZnFsxeQQ2z2rTuncoYANTP…", "use":"sig" } ] } 32
33. 公開鍵の復元 RS256の場合の公開鍵を復元するサンプルコード public RSAPublicKey publicKey(String n, String e) throws NoSuchAlgorithmException, InvalidKeySpecException { BigInteger modulus = new BigInteger(1, Base64.getUrlDecoder().decode(n)); BigInteger publicExponent = new BigInteger(1, Base64.getUrlDecoder().decode(e)); RSAPublicKeySpec spec = new RSAPublicKeySpec(modulus, publicExponent); return (RSAPublicKey) KeyFactory.getInstance("RSA").generatePublic(spec); } 33
34. フロー概要 1. 認可エンドポイントを response_type=code で遷移 2. 認証プロセスが完了すると、code パラメータと共に redirect_uri に指定したURLにリダイレクト 3. codeパラメータの値を使用して、トークンエンドポイントを 呼び出し、トークン（id_token、アクセストークン、リフ レッシュトークン）を取得 4. id_token の検証は、復元した公開鍵が使用可能 34
35. サードパーティ開始ログイン 35
36. LMS • Learning Management System eラーニング（オンライン学習）の配信や、受講者の学習進 捗・成績などを一元管理するための「学習管理システム」 36
37. e-Learningに関連する標準規格 • SCORM 米国の国防総省に属するAdvanced Distributed Learning Initiative（ADL Initiative）が制定したeラーニングのプラット フォームとコンテンツの標準規格 • LTI 国際的な非営利の標準化団体 1EdTech Consortium が策定した 標準 • xAPI あらゆる学習や経験のデータを記録・収集するための次世代e ラーニング技術標準規格 37
38. LTI • LMS（学習管理システム）と外部の学習アプリケーションやデ ジタル教材を安全に連携させるための標準規格 • シングルサインオン（SSO）で外部教材へのログイン • LMS側に成績データの書き戻し • LTI 1.3 で、認証やセキュリティの基盤として OAuth 2.0 や OpenID Connect の全面的採用 38
39. LTI 1.3 39
40. LTI 1.3のSSO • LMS間やLMSと任意のWebアプ リケーションを連携 • OIDCのInitiating Login from a Third Partyを活用 40
41. LTI 1.3の例 • JupyterHub • LTI Authenticator for JupyterHub 41
42. フローの概要 1. LMSからアプリケーションにログイン開始の呼び出し（LTI ローンチ） 2. アプリケーションは、response_type=id_token 等を指定し てLMSの認可エンドポイントにリダイレクト応答 3. 指定したアプリケーションのredirect_uriに、LMSから id_tokenの値を含むフォームデータがPOST 4. アプリケーションを起動（id_token の検証は、復元した公開 鍵が使用可能） 42
43. LMSに成績等を反映するフロー 1. アプリケーションはJWTを生成して、LMSにリクエスト 2. LMSはアクセストークンを返す 3. アクセストークンを使用して、成績等を反映する 43
44. 主体的アイデンティティ管理 44
45. 主体的アイデンティティ管理による連携 • セッション • OAuth 2.0 45
46. 主体的アイデンティティ管理の必要性 • id_token の有効期間は短い。Moodleの場合有効時間はわずか1 分 • 他社の認可サーバで発行される id_token のフォーマットがい つどのように変更されるか予測できない。さらに凍結や削除さ れる可能性 • 自社の組織あるいはアプリケーションでユーザの属性を保持す る仕組みを構築する 46
47. 主体的アイデンティティとの紐付け • id_token は、iss と sub でユニークに識別可能。自組織のアイ デンティティと、両者を紐付ける • 自組織のアイデンティティに必要な属性を付加 • アプリケーションは、セッションID等オパークトークンを活用 する 47
48. 参考文献 • 崎村夏彦著 (2021) デジタルアイデンティティー. 日経BP • 土岐孝平著 (2026) OpenID Connect入門. 技術評論社 • Phillip J. Windley (2024) デジタルアイデンティティのすべて. オライリー・ジャパン • Rob Koper, Colin Tattersall (2005) Learning design : a handbook on modelling and delivering networked education and training. Springer • Vlad Khononov (2025) ソフトウェア設計の結合バランス. イン プレス 48
49. 50 ありがとうございました