>
>
公開日
最終更新日
SAMLは認証情報に加え、属性情報をIdPから異なるドメインのSPへ伝達するための仕様です。なお、IPAはSAMLの説明に「認可情報」の伝達を含む表現を使用していますが、実務上SAMLが担うのは認証結果と属性の伝達であり、API権限の委譲はOAuth 2.0が担います。OAuthはAPIやデータへのアクセス権を委譲する認可フレームワークです。SAMLが「誰であるか」を確認する認証を担うのに対し、OAuthは「何を許可するか」を管理する認可を担い、両者は目的が異なります。
この記事では、企業でSaaS導入やSSO基盤の比較選定を担当する情報システム部員に向けて、SAML認証・OAuth・OIDC・SSOの違いを整理します。単に「SAMLは認証、OAuthは認可」と覚えるだけでなく、IdPとSPの認証フロー、SAMLアサーションの検証、OAuth 2.0で避けるべき実装、サービス対応状況による選定基準まで扱います。
この記事で確認したこと（確認日: 2026年06月30日）：IPAおよびデジタル庁の公開資料、GitHub・GitLab・MagicPod・さくらインターネットの公式ドキュメントを基に、現行のSAML認証フローと設定上の注意点を確認しました。
SAML・OAuth・SSOとは
SAML・OAuth・SSOは同じものではなく、認証、認可、ログイン体験という異なる役割を担います。
本記事のポイント
SAMLは、IdPが認証した利用者の情報をSPへ伝えるための仕様です。
OAuth 2.0は、パスワードを共有せずにAPIやデータへの権限を委譲する認可フレームワークです。
SSOは一度のログインで複数サービスを利用する仕組みであり、SAMLやOIDCはSSOを実現する技術です。
OAuthだけをログイン認証の根拠に使わず、認証にはSAMLまたはOIDCの検証済みトークンを使用します。
SAMLとOAuthの違いを判断する起点は、「誰がアクセスしているか」を確認したいのか、「どの操作やデータアクセスを許可するか」を管理したいのかです。前者は認証、後者は認可に当たります。
認証と認可の役割
認証は利用者の本人性を確認する処理です。たとえば、従業員がIdPへログインし、その結果をSaaSが信頼して利用を許可する場面が該当します。IPAは試験問題・解答例として公開した資料で、SAMLを認証情報、属性情報、アクセス制御情報を異なるドメインへ伝達するWebサービス仕様として説明しています。
認可は、認証済みの主体に対して「どのデータを、どの範囲で、どの期間利用できるか」を決める処理です。OAuth 2.0では、利用者が認可サーバーを通じてクライアントへアクセストークンを付与し、クライアントは許可された範囲でリソースサーバーへアクセスします。
SAML認証とSSOの違い
SAML認証は、異なるドメイン間で認証結果を受け渡すプロトコルです。一方のSSOは、利用者が一度認証されることで複数のサービスを利用できる状態や仕組み全体を指します。
つまり、SAML認証はSSOを実現する代表的な手段であり、SSOそのものではありません。Microsoft 365、Salesforce、Workdayなどの業務向けSaaSではSAMLが広く採用されています。既存の企業向けSaaSを統合する場合、対象サービスがSAML 2.0に対応していれば、IdPを起点としたSSOの構成を検討できます。
OAuthとSSOの違い
OAuthはSSOというログイン体験を直接定義する仕様ではありません。OAuthは、アプリケーションに対してデータやAPIのアクセス権を委譲するための仕組みです。
「OAuthによるSSO」と呼ばれる構成の多くは、OAuth 2.0に認証機能を加えたOpenID Connectを利用しています。アクセストークンはAPIアクセスのための資格情報であり、利用者のログイン状態を保証するIDトークンの代わりにはなりません。
用語 | 分類 | 主な役割 | 主な利用場面 |
|---|---|---|---|
SAML 2.0 | 認証連携プロトコル | 認証結果と属性情報をSPへ伝達します。 | 企業SaaSのSSO |
OAuth 2.0 | 認可フレームワーク | API・データアクセスの権限を委譲します。 | SaaS間のAPI連携 |
OIDC | 認証レイヤー | OAuth 2.0を基盤に利用者の認証情報を提供します。 | 自社Webアプリ、モバイルアプリのログイン |
SSO | 仕組み・利用体験 | 一度の認証で複数サービスを利用可能にします。 | 業務システム全体のログイン統合 |
▶ 関連記事: SCIMとは？自動プロビジョニングの仕組みとSAMLとの違い
▲ 認証（SAML/OIDC）と認可（OAuth 2.0）の役割と目的の違い
SAML・OAuth・OIDCの機能比較
企業SaaSのログイン連携にはSAML、API権限の委譲にはOAuth 2.0、自社アプリのモダンな認証にはOIDCを軸に選定します。
ただし、プロトコルの選択は用途だけでは決まりません。連携先が提供するプロトコル、既存IdP、利用者がアクセスするクライアントの種類、監査・アカウント管理の要件を合わせて判断します。
SAMLの特徴
SAMLはXMLベースの認証連携プロトコルです。IdPが利用者を認証し、認証結果を含むSAMLアサーションをSPが検証することで、SP側でパスワード入力を繰り返さずにログインできます。
企業向けSaaSでは、既存のSAML連携を維持する必要がある場合があります。Microsoft Learnの2026年6月更新資料では、企業顧客がSAMLを必要とする場合や、既存のSAML実装を活用する場合はSAMLを選択し、新しいSaaSやモバイルアプリではOIDCを標準候補とする考え方が案内されています。
OAuth 2.0の特徴
OAuth 2.0は、利用者のパスワードをクライアントへ渡さずに、限定されたアクセス権を付与するための認可フレームワークです。たとえば、外部サービスがカレンダー情報を読み取る場合、利用者は必要なスコープだけを許可し、クライアントはアクセストークンでAPIを呼び出します。
アクセストークンの用途はリソースサーバーへのアクセスです。アクセストークンの存在だけで利用者を認証済みと判断すると、トークンの発行先、対象リソース、利用者情報を適切に検証できません。
OIDCの特徴
OIDCはOAuth 2.0を基盤として認証機能を提供する仕様です。認可サーバーはIDトークンを発行し、クライアントは署名、issuer、audience、有効期限、nonceなどを検証して利用者を識別します。
デジタル庁は、OIDCには仕様上IdP Initiatedの認証フローが存在しないと説明しています。これは、標準的なOIDC認可フローでは認可リクエストをクライアント（SP側）が開始する設計になっているためです。OIDCにはThird-Party Initiated Loginに関する仕様も存在しますが、IdPポータルからアプリを起動する運用を前提にする場合は、連携先が対応する起動方式を公式ドキュメントで確認し、SP Initiatedで開始する導線や中継処理を含めて設計します。
▶ 関連記事: ソーシャルログインとは？仕組み・危険性とSSOとの違いを解説
SAMLによるSSOの認証フロー
SAML認証では、IdPが認証し、SPがアサーションを検証する責務分担を明確にすることでSSOを実現します。
IdPはIdentity Providerの略称で、利用者の認証を担う認証基盤です。SPはService Providerの略称で、SalesforceやSlackなど利用者がアクセスするSaaSを指します。
SP Initiatedの認証フロー
利用者がSaaSであるSPへアクセスします。
SPは認証要求を作成し、ブラウザを介して利用者をIdPへリダイレクトします。
IdPは利用者のログイン状態を確認し、未認証なら認証を実施します。
IdPは認証結果を含むSAMLレスポンスをブラウザ経由でSPへ返します。
SPはアサーションを検証し、問題がなければ利用者のセッションを開始します。
IPAの2025年資料でも、SAML認証はIdPが利用者認証を行い、認証成功後に発行するアサーションをSPが検証する実装方式として整理されています。アサーションは単なるログイン通知ではなく、利用者識別子、属性、発行者、対象サービス、有効期限などを含む信頼判断の材料です。
IdP Initiatedの認証フロー
IdPのアプリケーションポータルからSaaSアイコンを選び、SAMLレスポンスをSPへ送信する方式です。利用者の導線を集約しやすい一方、SPからの認証要求と結び付けるInResponseToを利用できない構成があります。
SP InitiatedとIdP Initiatedのどちらを使うかは、利便性だけで決めません。SP側が受け入れるフロー、リプレイ対策、ブックマークによる直接アクセス、障害時のログイン経路を設計書で整理してから決定します。
SAMLアサーションの検証項目
SP側では署名があることだけでは不十分です。少なくとも次の項目を検証します。
署名が信頼済みIdPの証明書で検証できること
Issuerが想定したIdPであること
Audienceが自サービスのエンティティIDと一致すること
RecipientとDestinationが受信先URLと一致すること
NotBeforeとNotOnOrAfterが許容時刻内であること
SP Initiatedの場合、InResponseToが発行済み認証要求と一致すること
NameIDや属性が対象アカウントの識別規則に合うこと
MagicPodの公式サポートでは、SAMLレスポンスのAssertion内にAttributeStatementが含まれること、Assertionへの署名が必須であることを案内しています。なお、SAML Web SSOではResponseへの署名またはAssertionへの署名のいずれを必須とするかは連携先SPの実装・プロファイル設定によって異なります。連携前に対象SPが要求する署名方式を公式ドキュメントで確認し、受信したResponse／Assertionの署名を適切に検証する構成を決定します。GitLabの公式ドキュメントは、SAML SSOでIdPが渡す最低限の情報としてemailを挙げ、証明書フィンガープリントにはSHA256の利用を案内しています。
▶ 関連記事: IDaaSとは？機能や導入メリットをわかりやすく解説
▲ SP Initiated方式におけるSAML SSO認証の5つの手順
SSO導入における運用課題と設定上の注意点
SSO導入で止まりやすい原因は、プロトコルの選択ミスよりも、証明書更新、属性設計、非常時アクセスを設計に含めないことです。
IdPは複数SaaSの入口になるため、停止や設定誤りの影響範囲が広くなります。導入前に通常時のログインだけでなく、証明書失効、IdP障害、退職者の無効化、緊急管理者アクセスまで決めておきます。
証明書とメタデータの更新漏れ
SAMLでは署名検証に証明書を使用します。IdPが署名証明書をローテーションすると、SP側のメタデータや証明書設定も更新が必要です。
デジタル庁の資料では、KeycloakのキーローテーションでレルムのSAMLメタデータが変更されるため、AWS IAM Identity Providerのメタデータ更新が必要になる事例を示しています。証明書期限の把握だけでは足りず、更新後のメタデータ反映、旧証明書との重複期間、テストアカウントによるログイン確認までを変更手順に含めます。
属性マッピングの不整合
メールアドレス、社員番号、部署コード、ロールなどの属性は、SaaSごとに要求形式が異なります。属性名の大文字・小文字、NameID形式、メールアドレス変更時の扱いが一致しないと、認証成功後に別アカウントが作成される、またはログインできない状態になります。
人事異動が多い組織では、識別子に変更されやすいメールアドレスだけを使うのではなく、不変の従業員IDを持てるかを検討します。ただし、SPがメールアドレスのみを識別子として受け入れる場合は、その制約を前提にメールアドレス変更時の移行手順を用意します。
OAuthを認証目的で誤用する失敗
やってはいけないのは、アクセストークンを受け取っただけで「この利用者はログイン済み」と判定する実装です。アクセストークンはAPIアクセスに使う資格情報であり、認証対象のクライアント向けに発行されたIDトークンではありません。
OIDCでログインを実装する場合、IDトークンの署名だけでなく、issuer、audience、exp、nonceを検証します。OAuth 2.0の認可コードフローでは、redirect_uriを事前登録値と厳密に一致させ、公開クライアントではPKCEを利用します。
セッション時間の過度な短縮
セッションを短くすれば安全性が上がるとは限りません。GitHubの公式ドキュメントでは、SAMLセッション期間が5分以下の場合、利用者がSAML認証ループから抜け出せなくなる可能性を案内しています。
セッション時間は、取り扱う情報の重要度、端末の管理状態、MFA再認証の頻度、利用者の業務中断を合わせて決めます。高権限操作だけ再認証を要求できるサービスでは、全操作を短時間で失効させるよりも、操作単位の認証強化を選べます。
▶ 関連記事: プロビジョニングとは？デプロイとの違いや種類を解説
要件に応じたプロトコル選定の判断基準
プロトコルは「連携先の対応方式」と「実現したい操作」を起点に選定し、IdP製品の機能比較はその後に行います。
SAML、OAuth、OIDCのいずれが優れているかではなく、相手サービスが受け入れる方式と、ログイン連携・API連携・自社アプリ認証のどれを解決したいかで選択肢が変わります。
要件 | 優先する方式 | 判断理由 | 追加確認項目 |
|---|---|---|---|
既存SaaSへ従業員がSSOでログインする | SAML 2.0 | 企業向けSaaSで広く採用されている認証連携方式です。 | SP Initiated対応、属性、証明書更新、対応プラン |
自社アプリへ従業員や顧客がログインする | OIDC | JSON・JWTを使うWebアプリやモバイルアプリと連携しやすい方式です。 | issuer、audience、nonce、PKCE、リダイレクトURI |
外部アプリへSaaSデータの利用を許可する | OAuth 2.0 | パスワードを共有せず、スコープ単位でAPI権限を委譲できます。 | スコープ、トークン有効期限、失効、監査ログ |
アカウントの入退社処理を自動化する | SCIM併用 | SAMLやOIDCは主に認証連携を担い、アカウント作成・停止は別機能です。 | 作成、更新、無効化、グループ同期、例外処理 |
連携対象の棚卸し項目
導入判断を進める場合は、利用中SaaSを一覧化し、各サービスを同じ項目で比較します。対応プロトコルの有無だけでは、運用開始後の手戻りを防げません。
利用部門と業務上の重要度
SAML、OIDC、OAuth 2.0、SCIMの対応状況
SSO対応プランと追加費用の有無
SP InitiatedとIdP Initiatedの対応状況
必要な属性、NameID形式、グループ連携の可否
MFA、端末制限、接続元制限の実装場所
監査ログの取得方法と保存期間
退職時のアカウント無効化方法
障害時に使うブレークグラスアカウントの管理方法
この一覧でSAML対応が確認できれば、既存IdPとのSSO連携を限定検証に進めます。SAML非対応でOIDCに対応している場合はOIDC連携を評価し、どちらも非対応なら個別ログインを残すか、認証ゲートウェイなど別方式を検討します。
対象・提供状況の確認
SAMLやSCIMは、同じSaaSでも契約プラン、契約地域、管理者権限によって利用可否が異なる場合があります。対象サービスの公式ドキュメントで対応プロトコルと契約プランが確認できれば導入設計へ進み、確認できなければSSO対象から一度外して個別アカウント管理の統制を設計します。
たとえば、クラウドサインはビジネスプランとエンタープライズプランでSAML 2.0によるSSOに対応しています（確認日: 2026年06月30日）。さくらインターネットは2025年6月25日、さくらのクラウドでSAML 2.0準拠の外部IdP連携によるSSO機能の提供開始を発表しています。契約プランや提供条件は変更される場合があるため、導入時点で各サービスの公式ドキュメントまたはサポート窓口で最新の対応状況を確認します。確認の結果、対応プランが要件を満たさない場合は、SSO対象から外して個別アカウント管理の統制を設計します。
▶ 関連記事: RBACとは？ABACとの違いや読み方・情シス向け設計手順を解説
▲ 実現したい要件から最適なプロトコルを選択する判断フロー
よくある質問
SAML認証、OAuth、SSOの違いで混同されやすい論点を、情シスの導入判断に必要な範囲で整理します。
SAML認証とSSOの違い
Q：SAML認証とSSOの違いは何ですか？
A：SSOは、一度のログインで複数サービスを利用できる仕組み全体です。SAML認証は、そのSSOを実現するためにIdPとSPの間で認証結果を受け渡すプロトコルです。
OAuthとSSOの違い
Q：OAuthとSSOの違いは何ですか？
A：OAuthは、アプリケーションへAPIやデータのアクセス権を委譲する認可フレームワークです。SSOはログインを一度に集約する仕組みであり、OAuth単体では利用者認証を保証しません。
SAMLとOIDCの使い分け
Q：SAMLとOIDCはどちらを選べばよいですか？
A：連携先SaaSがSAMLのみ対応している場合や、既存の企業向けSSO連携を維持する場合はSAMLを選びます。新規のWebアプリやモバイルアプリで認証を組み込む場合は、OIDC対応を優先して評価します。
SAMLアサーションの属性
Q：SAMLアサーションでは何を検証すればよいですか？
A：署名、Issuer、Audience、Recipient、Destination、有効期限、InResponseToを検証します。加えて、NameIDやメールアドレスなどの属性が、SP側のアカウント識別規則と一致するかを確認します。
まとめ
SAMLとOAuthの違いは、認証結果をサービス間で伝えるのか、APIやデータへのアクセス権を委譲するのかにあります。SSOは仕組み全体を指し、SAMLやOIDCはSSOを実現する技術です。
明日から着手するなら、まず利用中SaaSを一覧化し、SAML・OIDC・OAuth・SCIMの対応状況、契約プラン、必要属性、ログ取得方法、退職時の無効化方法を同じ表に記録します。SAML対応が確認できたサービスはIdPとの限定検証へ進み、証明書更新とブレークグラスアカウントを含めた運用手順まで決めてから対象を広げます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
橋爪兼続
ライトハウスコンサルタント代表。2013年海上保安大学校本科第Ⅲ群（情報通信課程）卒業。巡視船主任通信士を歴任し、退職後、大手私鉄の鉄道運行の基幹システムの保守に従事。一般社団法人情報処理安全確保支援士会の前身団体である情報処理安全確保支援士会の発起人。情報処理安全確保支援士(第000049号)。
