IdPフェデレーション
概要
複数のサービスがIdPと信頼関係を結び、ユーザーが一度のログインで複数のサービスを使用できる仕組み
イメージでいうと、Slackでログインをするときに、EntraIDログインにリダイレクトされて、ログインすればSlackにもログインされるようになるイメージ
構成要素 IdP と SP
IdP: Identity Provider
ユーザーに認証情報を管理しているサービス
Ex: EntraID, Google Workspace, Auth0
SP: Service Provider
ユーザーが実際にアクセスするときにしようするサービス
上記の例でいうとSlackにあたる
認証フロー
以下の認証フローを実施するためには、事前に SP と IdP とメタデータの交換(信頼関係)の設定が必要
8の IdP がブラウザに返した SAML レスポンスを SP に問い合わせをする必要がある。よって、SP は専用のエンドポイントを準備しておく必要がある
code:mermaid
sequenceDiagram
autonumber
actor User as 社員（ブラウザ）
participant Slack as Slack（SP）
participant Entra as Azure Entra ID（IdP）
Note over User,Entra: 【Phase 1】初回アクセス — 認証が必要
User->>Slack: Slack ワークスペースにアクセス
Slack-->>Slack: 未認証を検出
Slack->>User: Entra ID へリダイレクト（SAML AuthnRequest）
User->>Entra: SAML AuthnRequest を転送
Note over Entra: 条件付きアクセスポリシーを評価<br/>（デバイス準拠状況・ネットワーク等）
Entra->>User: Microsoft ログイン画面を表示
User->>Entra: ログイン実施
Note over Entra: 認証成功<br/>Entra ID セッション Cookie 発行
Entra->>Entra: SAML Assertion 生成（署名付き）
Note right of Entra: Assertion に含まれる属性:<br/>・NameID（UPN or email）<br/>・displayName<br/>・groups（Slack チャンネル割当用）
Entra->>User: SAML Response を返却（HTTP POST）
User->>Slack: SAML Response を転送（ACS URL へ POST）
Slack-->>Slack: 署名検証 + Assertion 解析
Slack-->>Slack: JIT プロビジョニング<br/>（初回はアカウント自動作成）
Slack->>User: Slack ワークスペースにログイン完了
Note over User,Entra: 【Phase 2】別サービスへアクセス — SSO でスキップ
User->>Slack: 2回目以降のアクセス
Slack->>User: Entra ID へリダイレクト
User->>Entra: SAML AuthnRequest を転送
Note over Entra: セッション Cookie 有効<br/>→ ログイン画面スキップ
Entra->>User: SAML Response を即時返却
User->>Slack: SAML Response を転送
Slack->>User: パスワード入力なしでログイン完了
上記を拡張すると、1つの IdP で複数の SP のログインが可能になる
IdP と SP 間のプロトコル
IdP と SP 間のやりとりは主に以下のプロトコルがよく使われている
SAML 2.0
トークン形式：XML
特徴：歴史が長く、企業向けSaaSで広く採用
主な用途：エンタープライズSSO
OpenID Connect (OIDC)
トークン形式：JWT (JSON)
特徴：OAuth 2.0の上に構築。軽量で開発者フレンドリー
主な用途：Web/モバイルアプリ
参考