SAMLの処理の流れを解説
SAML上での認証認可の切り分けができておらず、混乱していたのでここでまとめたいと思います。
この記事の目的
SAMLの登場人物（IdP、SP、ブラウザ）を整理し、どのような流れで処理を行うかを整理する
まずはシーケンス図
✅ SAMLの特徴：
| 比較項目 | SAML |
|---|---|
| 認証方式 | XMLベースのSAMLアサーション |
| 認証フロー | SAMLリクエスト → SAMLレスポンスで完結（1回のPOSTで認証） |
| トークン取得方法 |
HTTP POSTによるブラウザリダイレクトで、SAMLアサーションがSPにPOSTされる |
| セキュリティ設計 | 主にブラウザ間のPOST/Redirect |
| 認可の仕組み | 基本的に「認証のみ」／認可はSP側で処理 |
-
SAMLRequest → IdP にリダイレクト
-
ユーザーがIdPでログイン
-
SAMLResponse（署名付きXML）が SP に返却されて終わり
＝「1回のやり取りで認証完了」
OAuth/OIDCのように「認可コード → トークン」のステップは 不要／存在しない。
💬補足：OIDCの場合は？
OIDC（OpenID Connect）はOAuth 2.0に基づく認証プロトコルなので、「認可コード → トークン（ID Token, Access Token）」のステップがあります。
よって OktaとOIDC連携する場合は、トークンのやり取りあり
SAMLの認証・認可まとめ
SAMLでは認証（ユーザがだれであるか）をする作業が主となります。ここがOAuthやOIdPとの大きな違いです。
- SAML 本人確認
- OAuth アクセス制御
認証を行う際に登場人物を整理して、誰がどんな作業を行うのかという観点で整理しておくとよいかと思いました。