SAMLとOpenID Connectの基礎と利用シーン

© OpenID Foundation Japan © OpenID Foundation Japan 大学ICT推進協議会2025年度年次大会
SAMLとOpenID Connectの基礎と利用シーン一般社団法人 OpenIDファウンデーション・ジャパン理事・エバンジェリスト倉林雅 2025年12月1日

© OpenID Foundation Japan 倉林雅（kura） OpenIDファウンデーション・ジャパン理事・エバンジェリスト OpenID・OAuth・パスキー技術の啓発・教育活動に携わり、
現在は某インターネット企業にてプロダクトマネージャーを担当。 X: @kura_lab 著書「パスキーのすべて」増刷・絶賛発売中

© OpenID Foundation Japan アジェンダ 1. アイデンティティフェデレーションの基礎 2. SAMLの基礎とユースケース 3.
OpenID Connectの基礎とユースケース 4. SAMLとOpenID Connectの比較 4

© OpenID Foundation Japan • 定義 ◦ 異なるセキュリティドメイン（組織、システム）間で、アイデンティティ情報を信頼できる方法で共有する仕組み。 •
目的 ◦ シングルサインオン (SSO) の実現による利便性向上。 ◦ ユーザーと管理者双方のパスワード管理負担の軽減。 ◦ ユーザーごとのアクセス権限管理（認可）の集中化。 • 技術標準 ◦ SAML ▪ エンタープライズSSOのデファクトスタンダード。 ◦ OpenID Connect ▪ モダンなWeb・モバイル環境のデファクトスタンダード。アイデンティティフェデレーションとは 6

© OpenID Foundation Japan 主要な登場人物 7 役割略称概要 1
アイデンティティプロバイダー IdP (Identity Provider) OP (OpenID Provider) ユーザー認証を行い、アイデンティティを証明する側。（例：企業ディレクトリ、Microsft、Google、Okta） 2 サービス提供者 SP (Service Provider) RP (Relying Party) ユーザーのアイデンティティ情報に依拠してサービスを提供する側。（例：SaaSアプリケーション） IdP/OP User SP/RP アイデンティティ情報を連携ユーザー認証サービス利用

© OpenID Foundation Japan • 初期バージョンとベース (2002-2003) ◦ SAML 1.0
/ 1.1: OASISによって策定された初期規格。 ◦ XML を認証情報交換の基本フォーマットとして採用。 ◦ 当初は IdP起点 (IdP-Initiated) SSOが中心。 • 影響を与えた主要な規格 ◦ SAML 2.0は、複数の業界標準を統合して誕生。 • SAML 2.0の完成 (2005年) ◦ 上記の規格を統合し、企業間の連携に必要な機能を包括的に備えたエンタープライズSSOのデファクトスタンダードとして確立。 ◦ 特徴: XMLベースの複雑なセキュリティ（署名・暗号化）による厳格な信頼性の確立。 SAMLの歴史と源流：強固なエンタープライズSSOへ 9 規格推進団体 SAML 2.0への主な貢献 1 Identity Federation Framework（ID-FF） Liberty Alliance SP起点SSO、多様なHTTPバインディング（ HTTP-POST, Artifact）など、実用的なフローの確立。 2 Shibboleth（シボレス） Internet2 学術界の経験に基づく、信頼性の高いメタデータ交換、属性フィルタリングの概念。

© OpenID Foundation Japan • 認証情報: SAML Assertion ◦ ユーザーの認証結果と属性情報を含むXMLドキュメント。
◦ 常に署名され、機密情報は暗号化される。 • SAMLの技術的特徴 ◦ データ形式: XML (Extensible Markup Language) ◦ セキュリティ: XML署名とXML暗号化による厳格なメッセージ保護。 • 主要なXML要素 SAML 2.0のコア概念とXML構造 10 要素/属性説明必須条件 1 <saml:Issuer> メッセージの発行元（ IdPまたはSP）のEntityID。必須 2 <saml:NameID> ユーザーを一意に識別するための ID。SPはこれをキーにユーザーを特定。必須 3 <saml:AudienceRestriction> このアサーションの宛先（ SPのEntityID）。セキュリティ上、SPは必ず検証する。必須 4 <saml:AttributeStatement> ユーザーの付加情報（部署、メールアドレス、ロールなど）を格納。 SPの認可判断に使用。任意 5 <ds:Signature> デジタル署名。メッセージの完全性と真正性を保証する。必須セキュリティ推奨

© OpenID Foundation Japan • 管理者による手動操作 ◦ 新規連携の開始: IdP管理者が、新しいSPとのSAML連携を設定するために、SPから提供されたメタデータXMLファイルをIdPシステムにアップロードする、またはインポート
する。 • スケジュールされた自動ポーリング（定期更新） ◦ URLのポーリング: SPが公開しているメタデータURL（例: https://sp.example.com/saml/metadata）に対し、IdPシステムが設定された間隔（例：1時間ごと、24時間ごとなど）でHTTP GETリクエストを送信し、メタデータを取得する。 • SAMLメッセージ受信時の動的取得（稀なケース） ◦ 連携情報がIdPに未登録であったり、キャッシュが古い場合に、受信した SAMLメッセージをトリガーとしてメタデータ取得を試みることがある。 SAML SPの登録方式 11

© OpenID Foundation Japan • フローの全体像 ◦ ユーザーアクセス: ユーザーがSPにアクセス (未認証)。
◦ AuthnRequest生成: SPは認証要求 SAML AuthnRequest を生成し、SPの秘密鍵で署名する。 ◦ リダイレクト: ブラウザを通じてIdPのSSOエンドポイントへリダイレクト。 ◦ 認証: IdPがユーザーを認証し、 SAML Responseを生成。 ◦ Response署名/暗号化: IdPは自身の秘密鍵で署名し、機密情報を SPの公開鍵で暗号化する。 ◦ コールバック: ブラウザを通じてSPのACS URLへリダイレクト（HTTP-POST）。 ◦ 検証・復号: SPがResponseを検証し、セッションを確立。 • SPの重要な検証 SAMLフローの詳細：SP起点SSOとセキュリティ 12 項目使用する鍵/情報目的 1 署名検証メタデータのIdP公開鍵メッセージが正しいIdPから来たこと（真正性）と改ざんがないこと（完全性）を証明。 2 復号化 SP自身の秘密鍵暗号化されたアサーション内のユーザー情報を取得（機密性）。 3 Audience検証 SPのEntityID アサーションが自分宛てに発行されたものであることを確認。

© OpenID Foundation Japan 13 SP-Initiated SSO End-User User Agent
SP IdP

© OpenID Foundation Japan 14 0-1.ログイン画面   メールアドレス送信 0-2.メールアドレス SP-Initiated
SSO End-User User Agent SP IdP SPにメールアドレス情報を送信

© OpenID Foundation Japan 15 0-1.ログイン画面   メールアドレス送信 0-2.メールアドレス SP-Initiated
SSO End-User User Agent SP IdP SPの秘密鍵で署名したAuthnRequestを生成するメールアドレスのドメインから然るべきIdPへリダイレクトしAuthnRequestを送信する（HTTPステータス302） 1.AuthnRequest

© OpenID Foundation Japan 16 0-1.ログイン画面   メールアドレス送信 1.AuthnRequest 2.ログイン画面
3.クレデンシャル   情報入力 0-2.メールアドレス SP-Initiated SSO End-User User Agent SP IdP IdP上に登録されているアカウントにログインする

3.クレデンシャル   情報入力 0-2.メールアドレス 4.Assertionを含むSAML Response SP-Initiated SSO End-User User Agent SP IdP IdPの秘密鍵で署名し、機密情報はSPの公開鍵で暗号化した Assertionを生成する

3.クレデンシャル   情報入力 0-2.メールアドレス 4.Assertionを含むSAML Response SP-Initiated SSO End-User User Agent SP IdP JavaScriptを利用して SPへAssertionをPOSTする

3.クレデンシャル   情報入力 0-2.メールアドレス 5.Assertionを検証   属性情報抽出 SP-Initiated SSO End-User User Agent SP IdP 4.Assertionを含むSAML Response Assertionの署名を IdPの公開鍵で検証し成功ならば、機密情報をSPの秘密鍵で復号して抽出

3.クレデンシャル   情報入力 0-2.メールアドレス 5.Assertionを検証   属性情報抽出 6.ログインセッション   発行 7.ログイン完了 SP-Initiated SSO End-User User Agent SP IdP 4.Assertionを含むSAML Response セッションを発行しログイン状態にする

3.クレデンシャル   情報入力 0-2.メールアドレス 5.Assertionを検証   属性情報抽出 6.ログインセッション   発行 7.ログイン完了 SP-Initiated SSO End-User User Agent SP IdP 4.Assertionを含むSAML Response

© OpenID Foundation Japan • エンタープライズ SSO (B2E) ◦ 企業が自社のIdP（例：ADFS,
Shibboleth IdP）を介して、Box, SalesforceなどのSaaSアプリケーションにログインする場合。 • 企業間連携 (B2B) ◦ 複数の大企業が個別のIdPを持ち、相互に信頼してSSOを行う場合。 • 学術認証フェデレーション ◦ 大学や研究機関が共通の認証基盤（例：日本のGakuNin）を利用し、学術リソースにアクセスする場合。 SAML 2.0のユースケース 22

© OpenID Foundation Japan • SAMLの強み ◦ 厳格なセキュリティ : XML署名/暗号化による、最高レベルのメッセージ保護。
◦ 実績と信頼: 長年の利用実績があり、エンタープライズ環境での安定性が高い。 ◦ 属性交換の細かさ: ユーザー属性の定義と交換ルールが詳細に規定されている。 • 留意点 ◦ 複雑性: 実装やデバッグが複雑になりがち（ XMLパーシング、証明書管理）。 ◦ 重量級: メッセージサイズが大きく、モバイルや SPAには不向き。 SAML 2.0の強み・留意点 23

© OpenID Foundation Japan • 基盤となるプロトコル ◦ OAuth 2.0 (2012年):
認証ではなく、認可（リソースへのアクセス許可）のためのプロトコル。 ◦ OAuth 2.0は「誰が」アクセスしているかの情報（認証）を持たない。 • OIDCの誕生 (2014年) ◦ OIDC は OAuth 2.0の上に認証レイヤーを追加したもの。 ◦ OAuth 2.0で認可に使われるトークンフローを流用し、認証情報を運ぶID Tokenを導入。 OpenID Connect (OIDC) の歴史 25

© OpenID Foundation Japan • 設計思想：モダンなWeb環境への適応 ◦ 軽量性: SAMLのXMLではなく、JSONをベースに採用。 ◦
モバイル/SPAへの最適化: RESTful APIとの親和性が高く、ブラウザ以外のクライアントでも容易に実装可能。 ◦ 簡素化: 認証と認可の分離により、フローをシンプルに保つ。 • 結論 ◦ OIDCは、SAMLの「認証と属性交換」の機能と、OAuth 2.0の「認可（APIアクセス）」の機能を組み合わせた、現代のインターネットに最適なプロトコル。 OIDCの設計思想 26

© OpenID Foundation Japan • 動的クライアント登録 (Dynamic Client Registration) ◦
RPがOPに対し、プログラム的に登録情報を送信し、 OPがリアルタイムで登録を受け付け、IDとシークレットを発行する。 ◦ RPのメタデータをJSON形式で記述し、登録エンドポイントに HTTP POSTリクエストする。 • 静的クライアント登録 (Static Client Registration) ◦ RPの情報をOPの管理画面や設定ファイルに手動で事前に登録する方法。 ◦ エンタープライズ環境やクライアント数が限定されている場合に用いられる。 OIDC RPの登録方式 27

© OpenID Foundation Japan • 3つの主要なトークン • 3つの主要なエンドポイント OIDCのコア概念：トークンとエンドポイント 28
トークン概要 1 ID Token 認証結果（ユーザー認証情報）を運ぶ。 OIDCの中心。 2 Access Token UserInfo Endpoint や他のAPIにアクセスするための認可証。 3 Refresh Token Access Tokenの有効期限が切れた際に、再認証なしで新しいトークンを取得するための鍵。トークン概要 1 Authorization Endpoint ユーザーを認証し、認可コードを発行。 2 Token Endpoint 認可コードを ID Token/Access Token に交換。 3 UserInfo Endpoint Access Tokenを使って、ユーザーの追加属性を取得するための API。

© OpenID Foundation Japan • 認証情報としてOPから発行される。 • フォーマットは「JSON Web Token
(JWT、ジョット)」 • 構造：「<Header>.<Payload>.<Signature>」 • Claim：Payloadに含まれる情報。OPが「主張（Claim）する属性情報」 OIDCのコア概念：IDトークン 29 主要なClaim 概要 1 iss (Issuer) 発行者（OP）の識別子。 2 aud (Audience) 受信者（RP）のクライアントID。 3 sub (Subject) ユーザーの一意な識別子。

© OpenID Foundation Japan • フローの全体像（認可コードフロー） ◦ 認可リクエスト (RP →
OP): RPがユーザーをOPにリダイレクト。 ◦ client_id, redirect_uri, scope (openid profile emailなど) を指定。 ◦ 認証と同意: OPがユーザー認証後、RPへの情報提供の同意を求める。 ◦ 認可コード発行: OPがRPのredirect_uriに認可コードを返す。 ◦ トークンリクエスト (RP → OP): RPはバックチャネル（サーバー間通信）でToken Endpointにコードを送信。この際、 client_secretで自身を証明する。 ◦ トークン発行: OPが ID Token, Access Token, Refresh Token を発行。 • RPのID Token (JWT) 検証 ◦ 署名検証: OPの JWKS (JSON Web Key Set) エンドポイントから公開鍵を取得し、トークンの署名を確認（改ざん防止）。 ◦ クレーム検証: OIDCフローの詳細：認可コードフロー 30 主要なClaim 検証内容 1 iss iss（発行者）が正しい OPであること。 2 aud aud（Audience）がRPのclient_idと一致すること。 3 exp exp（有効期限）が切れていないこと。

© OpenID Foundation Japan 31 End-User User Agent RP OP
UserInfo EP Authorization Code Flow

© OpenID Foundation Japan 32 0-1.処理開始 0-2.処理開始 Authorization Code Flow
End-User User Agent RP OP UserInfo EP

© OpenID Foundation Japan 33 0-1.処理開始 1.Authorizationリクエスト 0-2.処理開始 Authorization Code
Flow RPからOPへ認証・認可を User Agentを利用して GETのリダイレクト（もしくはPOST）でリクエスト End-User User Agent RP OP UserInfo EP

© OpenID Foundation Japan 34 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画面 3.クレデンシャル  
情報入力 5.同意 4.同意画面 0-2.処理開始 Authorization Code Flow OPがログイン・同意をユーザーに要求 End-User User Agent RP OP UserInfo EP

情報入力 5.同意 4.同意画面 0-2.処理開始 6.Authorization Code Authorization Code Flow ユーザーが認可した情報が Authorization CodeとしてUser Agentを通じて RPへ返却される Access Tokenなどを直接Clientサイドへ返却せず有効期限の短い一時トークンとして Authorization Codeを返却するため強固 End-User User Agent RP OP UserInfo EP

情報入力 5.同意 4.同意画面 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) Authorization Code Flow Authorization Codeに加えてサーバー間で Client IDとClient Secretによるクライアント認証を行う End-User User Agent RP OP UserInfo EP

情報入力 5.同意 8.Access Token/ID Token 4.同意画面 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) Authorization Code Flow 認可のAccess Tokenと OPが行ったユーザー認証の情報を含む ID TokenをJSONに含めて返却 End-User User Agent RP OP UserInfo EP

情報入力 5.同意 8.Access Token/ID Token 4.同意画面 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 9.ログインセッション   発行 10.ログイン完了 Authorization Code Flow ID Tokenを検証しRPでログイン処理を完了 End-User User Agent RP OP UserInfo EP

情報入力 5.同意 8.Access Token/ID Token 11.Access Token 4.同意画面 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 9.ログインセッション   発行 10.ログイン完了 Authorization Code Flow 属性情報の取得が必要な場合は UserInfoエンドポイントへAccess Tokenを送信 End-User User Agent RP OP UserInfo EP

情報入力 5.同意 8.Access Token/ID Token 11.Access Token 12.Claims 4.同意画面 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 13.属性情報取得完了 9.ログインセッション   発行 10.ログイン完了 Authorization Code Flow 各ClaimがJSONで返却される End-User User Agent RP OP UserInfo EP

情報入力 5.同意 8.Access Token/ID Token 11.Access Token 12.Claims 4.同意画面 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 13.属性情報取得完了 9.ログインセッション   発行 10.ログイン完了 Authorization Code Flow End-User User Agent RP OP UserInfo EP

© OpenID Foundation Japan • ソーシャルログイン ◦ Google, LINEなどのコンシューマーIDPを使ったWebサイトへのログイン。 •
モバイルアプリ認証 ◦ ネイティブアプリ（iOS/Android）が組み込みブラウザを通じて認証を行う場合。 • SPA (Single Page Application) ◦ JavaScriptがメインとなるモダンなWebアプリケーション。 • API連携・マイクロサービス ◦ Access Tokenを使って、サービス間のAPIアクセスを保護・認可する場合。 OIDCのユースケース 42

© OpenID Foundation Japan • OIDCの強み ◦ 軽量性: JSON/JWTベースのため、処理が高速でモバイルに適している。 ◦
開発の容易さ : RESTful APIに基づき、標準ライブラリ（SDK）が豊富。 ◦ 認可との統合 : OAuth 2.0を基盤とするため、認証からAPIアクセス（認可）まで一貫して管理できる。 • 留意点 ◦ Attribute取得: 属性を取得するためにUserInfo Endpointへの追加のAPIコールが必要となる場合がある。 OIDCの強みと留意点 43

© OpenID Foundation Japan SAML vs OIDC: 技術スタックの決定的な差 45 比較項目
SAML 2.0 OpenID Connect (OIDC) ベース技術 XML (XML署名/暗号化) JSON (JWT/RESTful API) サービス登録管理者による手動、定期更新、 SAMLメッセージ受信時の動的取得動的登録、静的登録メッセージ SAML Assertion (重量級) ID Token (JWT) + Access Token (軽量級) セキュリティ XML署名（複雑） JWT署名（公開鍵で検証）連携先エンタープライズ、レガシーシステムモバイル、SPA、クラウドサービス実装難易度高い低い

© OpenID Foundation Japan • SAMLを選ぶ時 ◦ 連携相手: 連携先が既存のエンタープライズシステムであり、 SAMLにしか対応していない場合。
◦ 環境: 厳格なセキュリティ要件があり、メッセージ全体の XML暗号化が求められる場合。 ◦ 実績: 複雑な企業間連携において、長年の実績と安定性を重視する場合。 • OIDCを選ぶ時 ◦ クライアント: モバイルアプリや SPAなど、軽量な認証が求められる場合。 ◦ 用途: 認証後にAPIアクセス（認可）を頻繁に行う場合。 ◦ トレンド: Google, Amazon, Microsoftなど、主要クラウドサービスとの連携が主となる場合。 • 現代のトレンド ◦ 新規のID連携開発では、その柔軟性・軽量性から OIDCが主流となりつつある。 ◦ SAMLは、既存の企業連携や学術連携の分野で不可欠な役割を維持している。どちらを選ぶべきか？ 46

SAMLとOpenID Connectの基礎と利用シーン

SAMLとOpenID Connectの基礎と利用シーン

More Decks by kura

Other Decks in Technology

Featured

Transcript