SAML（Security Assertion Markup Language）はOASIS（標準化団体）が2005年にv2.0として完成させた、XMLベースのシングルサインオン（SSO）プロトコルです。「ユーザがIdP（Identity Provider）にログインすると、そこに紐づく複数のSP（Service Provider）にも自動ログインできる」仕組みで、エンタープライズSSOの古典として2000年代後半から普及。近年はOIDCに置き換えが進みつつも、企業向けSaaSでは依然として標準対応プロトコルです。
この記事の目次
- SAMLの登場人物
- SAMLの典型的なフロー
- SAMLとOIDCの比較
- SAMLでよくあるトラブル
- まとめ
SAMLの登場人物
SAMLには大きく IdP（Identity Provider、認証する側＝Okta、Azure AD等）、SP（Service Provider、サービス本体＝Salesforce等）、ユーザ（ブラウザを操作する人）の3者が登場します。ユーザがSPにアクセスすると、IdP にリダイレクトされてログイン、IdPは「この人は本物です」というXML文書（Assertion）を作成、SPに渡す、という流れです。
Assertionには「ユーザ名」「所属」「権限」などの属性が含まれ、SP はこれを元にユーザを識別。AssertionはIdPの秘密鍵で署名されており、SP は公開鍵で正当性を検証します。
SAMLの典型的なフロー
代表的なフロー「SP-initiated SSO」では、まずユーザがSP（例: Salesforce）にアクセスし、未認証ならIdPへリダイレクトされます。IdP（例: Okta）でログインを完了すると、SAML AssertionがHTTP POSTでSPへ返され、ユーザはセッションを得てサービスを利用開始します。
別パターンの「IdP-initiated SSO」では、ユーザがまずIdPのダッシュボードからSPを選択し、IdPがそのままAssertionを送る形に。企業内SSOポータルでよく使われる動線です。
SAMLとOIDCの比較
認証SSOプロトコルにはSAMLと並んでOpenID Connect（OIDC）があり、両者は競合しつつ共存しています。SAMLはXMLベースで重め、エンタープライズ向き。OIDCはJWT中心で軽量、モバイル/SPA向き。
新規SaaSの認証実装は OIDC が第一候補ですが、企業向けの大規模SaaSは「SAMLにも対応してください」と要求されることが多く、両対応するのが商用SaaSの実情です。OktaやAzure ADは両プロトコルをサポートし、SP側がどちらを使うかを選ぶ構図です。
SAMLでよくあるトラブル
SAML 実装の現場で頻発するトラブルは、時刻ずれ・証明書期限切れ・URL不一致など、設定ミスがほとんど。「先週まで動いていたのに今朝から認証エラー」の犯人は大抵 IdP 側か SP 側の証明書ローテーション失敗です。
また Single Logout（SLO、全SP一斉ログアウト）の挙動が実装によってバラバラなのもSAMLの古さゆえ。「IdPでログアウトしたのにSPには残っている」みたいな現象は実装依存で起きやすく、テスト時に意識して確認する必要があります。
まとめ
SAMLはエンタープライズSSOの古典として、企業向けSaaSでは依然必須の対応プロトコルです。新規はOIDCが主役ですが、SAMLが何をしているかを理解しておくと、業務系の認証統合で必ず役に立ちます。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント