SAML認証とは？仕組み・SaaSでの使い方・OAuthやOpenID Connectとの違いを解説

SAML認証は、IdPで済ませた認証の結果を、ログイン先のサービスが受け取る形で、ブラウザ経由のシングルサインオンを実現する仕組みです。仕事で使うSaaSや社内のサービスが増えた今、ログインの手間を減らすだけでなく、認証のやり方をそろえたり、権限の管理をまとめたりするうえでも使われています。

ただし、SAMLを「SSOができる規格」くらいの理解で入れると、属性の渡し方、証明書を更新する作業、ログアウトの動きの差といった点でつまずきやすくなります。この記事では、SAMLの意味、仕組み、メリット、気をつけたい点を順に見ます。あわせて、OAuthやOpenID Connectとの違い、よくある使い方、入れる前に見ておきたい点も説明します。

SAML認証とは

SAMLは、別のドメインの間で、ユーザーが認証済みであることや、ユーザーにひもづく属性を受け渡すための標準です。やり取りの中心になるのは XML で表したアサーションで、そこに「この人は IdP で認証済みである」「どのメールアドレスや所属を持つか」といった情報を載せます。

企業で多い使い方は、社内の認証を起点にして、複数の SaaS へ入る形です。このとき、ログイン先のサービスは、原則としてユーザーのパスワードそのものを受け取りません。IdP が出した認証の結果を受け取り、それを確かめたうえでログインを通します。

シングルサインオンとは

シングルサインオンは、一度のログインで複数のサービスへ入れるようにする考え方です。これがないと、SaaS や社内のサービスごとにログインが必要になり、パスワードの使い回しや、退職した人のアカウントが残るといった事故も起きやすくなります。認証を一か所に集めると、多要素の認証や場所・端末の条件もそろえやすくなります。

シングルサインオンについて詳しく知りたい方は、こちらもご覧ください。

「シングルサインオンとは？ 仕組みやメリットを解説」

SAMLでよく出る用語

• IdP：ユーザーを認証し、その結果を出す側
• SP：ログイン先になるサービス
• SAMLアサーション：認証の結果やユーザーの属性をまとめた XML データ
• メタデータ：連携に使う URL や証明書などの必要な情報
• ACS：SP が SAMLResponse を受け取る受信先
• NameID：ユーザーを見分けるための識別子
• 属性：メールアドレス、所属、グループなどの追加の情報
• バインディング：HTTP-Redirect や HTTP-POST など、SAML メッセージを運ぶ方法

SAMLが合う場面

SAMLは、企業の認証を起点にして外部の SaaS へ入る用途と相性がよく、多くの企業向けサービスで広く使われています。すでに IdP を中心にした運用がある環境では、相手のサービスも SAML に対応していれば広げやすい方式です。

OAuthとSAMLの違い

OAuth 2.0 と SAML は、そもそもの役目が違います。OAuth 2.0 は、第三者のアプリに限られたアクセス権を渡すための認可の枠組みです。一方の SAML は、認証の結果と属性を相手へ渡してログインを成立させる場面でよく使われます。

• 認可：あるデータや API へ入ってよい権限を与えること
• 認証：その人が誰かを確かめること

たとえば、写真アプリがクラウドストレージの写真を読みたいとき、ユーザーのパスワードを渡す代わりに「写真だけ見てよい」という権限を渡すのが OAuth 2.0 の典型です。これに対し、仕事のログインで「この人は誰か」をログイン先へ伝えたいときは、SAML のほうが話が合います。

混同しやすい点

OAuth 2.0 にもログイン画面が出てくるため、これだけで認証の方式だと受け取られがちです。ただ、OAuth 2.0 そのものは認可の仕様であり、標準の形でユーザー認証を定めたものではありません。ログインに使うなら、認証のための情報を足した OpenID Connect のような方式を使うのが一般的です。

OpenID ConnectとSAMLの違い

OpenID Connect は OAuth 2.0 の上に認証の仕組みを足した方式です。ログインしたユーザーが誰かを ID トークンで伝え、このトークンは一般に JWT で表されます。SAML は XML のアサーションを使うため、使うデータ形式も発想も少し違います。

選ぶときに差が出やすい点

• 相手の対応：SaaS が SAML のみ対応、または OpenID Connect のみ対応ということがある
• アプリの形：Web アプリや API を中心に作るときは OpenID Connect が入れやすいことが多い
• 今ある運用：すでに IdP を中心に SAML を広げているなら、そのまま展開しやすい

企業では、SaaS は SAML、社内で作ったアプリは OpenID Connect というように分けて使うことも珍しくありません。大事なのは、どの方式を選ぶかだけでなく、認証の強さとアカウント運用をそろえられるかです。

SAML認証の仕組み

SAML認証では、利用者、SP、IdP の三者がやり取りします。通常のログインと違い、IdP が認証を受け持ち、SP はその結果を受け取って確かめます。

SP initiated と IdP initiated

SAML の手順は、どちらから始まるかで二つに分けて説明されることが多いです。

利用者が SP から入る場合

1. 利用者が SP にアクセスする
2. SP が AuthnRequest を作り、利用者を IdP へ送る
3. 利用者が IdP で認証する
4. IdP が SAMLResponse を出す
5. 利用者のブラウザ経由で SP の ACS へ届き、SP がそれを確かめてログインを通す

利用者が IdP から入る場合

1. 利用者が IdP にアクセスする
2. 利用者が IdP で認証する
3. 利用者が使う SP を選ぶ
4. IdP が SAMLResponse を出し、ブラウザ経由で SP へ送る
5. SP がそれを確かめてログインを通す

どちらを使うか

普段の URL からそのまま入る使い方なら、SP から始まる手順が合いやすいことが多いです。一方、社内ポータルのように IdP 側からサービスを選ぶ導線なら、IdP から始まる手順も使われます。どちらがよいかは、相手のサービスがどちらを前提にしているか、ログの取り方をどうしたいかで決めます。

SAMLResponse に入る主な情報

SAMLResponse には、認証が通ったかどうか、NameID、属性、有効な期間などが入ります。SP は、それが想定した IdP から出たものか、自分向けのものか、まだ有効か、といった点を見ます。

受け入れ時に見る点

• 署名：改ざんされていないか
• Audience：受け手がその SP か
• Recipient：送信先が想定した ACS か
• NotBefore / NotOnOrAfter：まだ有効な期間に入っているか
• InResponseTo：要求に対する応答として成り立っているか

ここが甘いと、受け入れるべきでない応答まで通してしまうおそれがあります。入れる前に、相手のサービスが何を見ているかを確かめておくと安全です。

バインディングと実装で見やすい点

SAML メッセージを運ぶ方法としては、HTTP-Redirect や HTTP-POST などがあります。Web ブラウザを使う SSO では、要求を Redirect で送り、応答を POST で受ける形がよく見られます。

運用で問題になりやすい点

• RelayState：ログイン後の飛び先を持たせる値で、相手ごとに制約があることがある
• 属性が多い場合：メッセージが大きくなり、制限に当たることがある
• ブラウザの制約：Cookie やポップアップの扱いが影響することがある

SSO は規格だけ見れば済むわけではありません。実際にはブラウザや社内ネットワークの条件でも動きが変わるため、使う端末とブラウザで事前に試すことが大切です。

署名と証明書

SAML では、SAMLResponse やアサーションに署名を付け、それを受け手が確かめる形が一般的です。必要に応じて暗号化も使われますが、暗号化だけで十分というわけではなく、署名を見て正しい相手から届いたものかを確かめることが欠かせません。

証明書を更新する作業が重要な理由

SAML で使う証明書には有効な期間があります。期限切れや更新もれが起きると、SSO が止まるおそれがあります。しかも、IdP 側だけ差し替えれば終わりとは限らず、SP 側でメタデータを入れ替える作業や、新旧の証明書をしばらく併用する段取りが要ることもあります。

SAML認証とSSO運用の見方

SAML では IdP が認証を受け持つため、SP が SAML に対応していれば、SSO を広げやすくなります。ただし、ログインを通す仕組みと、アカウントを作る・止める仕組みは別で考える必要があります。

フェデレーションとは

SAML でよく出るフェデレーションとは、別のドメインの間で、認証の状態や属性を受け渡す考え方です。やり取りするのは ID とパスワードそのものではなく、認証結果と属性を入れたアサーションです。

シングルログアウトの扱い

シングルログアウトは、IdP または SP でログアウトしたときに、関連するセッションも終わらせるための仕組みです。ただし、すべてのサービスが同じように対応しているわけではなく、動きに差が出ることがあります。共有の端末が多い環境では、セッションの切れ時間や端末ロックもあわせて考える必要があります。

アカウントの作成と停止は別で見る

SAML はログインの成否を受け渡す仕組みであり、ユーザーの作成・変更・削除を自動で行う標準ではありません。退職や異動のときに SaaS 側のアカウントを確実に止めたいなら、SCIM などの仕組みや、初回ログイン時に作る方式もあわせて考えると管理しやすくなります。

SAML認証のメリット

ログインの手間を減らせる

複数のサービスで何度もログインしなくてよくなるため、日々の作業が楽になります。SaaS の数が多い環境ほど、差が出やすい点です。

認証のやり方をそろえやすい

認証を IdP に集めることで、多要素の認証やアクセス条件を一貫してかけやすくなります。サービスごとの認証のばらつきが出にくくなるのは大きな利点です。

属性と権限をまとめて見やすい

IdP 側で属性やグループを持たせると、どのサービスへ入れてよいかをそろえやすくなります。異動や組織が変わるときでも、サービスごとの個別に対処を減らしやすくなります。

SAML認証の注意点

IdP が止まると影響が広がる

認証を IdP に集めるため、IdP が止まったり侵害されたりしたときの影響は大きくなります。管理者の多要素の認証、権限の絞り込み、監査ログ、予備系、障害時の手順を先に決めておく必要があります。

連携の設定が細かい

SAML では、メタデータ、証明書、ACS、NameID、属性、署名の要否など、決めることが多くなりがちです。相手のサービスごとに必要な値が違うこともあり、入れるまでに手間がかかることがあります。

証明書の更新を忘れられない

証明書の期限が切れると SSO が止まるおそれがあります。更新の予定、周知、試験、切り戻しまで含めて、年ごとの作業として回せる形にしておくことが大切です。

相手ごとの実装差がある

SAML は標準ですが、SP ごとに受け入れる条件や厳しさが違うことがあります。署名を見るか、Audience や Recipient をどこまで見るか、必須の属性は何かを、事前の試験で確かめておく必要があります。

SAML認証の利用例

企業の中でよくある使い方

グループウェア、勤怠、経費、CRM、文書を管理など、日々の仕事で使うサービスが増えるほど、SSO の価値は高まります。クラウドの利用が増えた会社では、SAML を使って認証をまとめる例が多く見られます。

SaaS へ広げるときの形

社内の IdP で認証し、各 SaaS へ入る形が代表例です。サービスごとに ID とパスワードが散らばる状態を避けやすくなり、退職者の残りや権限のつけすぎも抑えやすくなります。

SAML認証を入れる前に見る点

どこまでを対象にするか

最初に、どのサービスと利用者を対象にするかを決めます。主要な SaaS だけ先にまとめるのか、社内ポータルまで含めるのかで、必要な作りは変わります。

認証をどう強くするか

SSO は便利ですが、IdP を突破されると影響が大きくなります。多要素の認証に加え、端末や場所の条件も含めて、どこまでかけるかを先に決めておく必要があります。

どの属性を渡すか

どの属性を相手へ渡し、どの値でアクセスを分けるかを先に決めておくと、あとで運用が崩れにくくなります。最初は必要なものだけに絞るほうが無理が出にくいです。

アカウント運用まで含めて考える

SSO だけでは、使わなくなったアカウントの整理までは自動になりません。退職、休職、委託先の切り替えといった場面も含め、SaaS 側のアカウントをどう止めるかまで決めておく必要があります。

証明書の更新作業を年次の仕事に入れる

証明書の更新は、忘れると大きな事故につながります。担当者が変わっても迷わないよう、更新の手順を文書にし、試験のやり方も残しておくことが重要です。

運用しやすさと監査のしやすさを見る

製品やサービスを選ぶときは、機能の多さだけでなく、ログの見やすさ、管理者の保護、障害時の切り分けのしやすさまで見ておくと、入れたあとで困りにくくなります。

まとめ

SAML認証は、別のドメインの間で認証結果と属性を受け渡し、シングルサインオンを実現するための代表的な方式です。基本は、利用者、SP、IdP の三者でやり取りし、IdP が認証を受け持ち、SP がその結果を確かめてログインを通す、という形です。

入れるときは、便利さだけでなく、IdP の守り、属性の渡し方、証明書を更新する作業、アカウント運用まで含めて考える必要があります。相手の対応している方式と自社の運用に合う形を選ぶことが大切です。