SAML vs OIDC vs OAuth 2.0の違いとは？クラウドSSO・フェデレーション設計で使い分ける認証プロトコル完全ガイド

クラウド移行を進めているとき、SSOやフェデレーション設定で「SAMLで連携するのか、OIDCを使うのか、OAuth 2.0とは何が違うのか」と頭が混乱した経験はないだろうか。オンプレ時代はActive DirectoryとKerberosの組み合わせで認証が完結していたのに、クラウド移行を機にこれらのプロトコルを正確に理解する必要が出てくる。

この記事では、SAML 2.0・OpenID Connect（OIDC）・OAuth 2.0の3つを比較し、AWSとAzureの実装シナリオを交えながら「どのプロトコルをいつ選ぶか」の判断基準を整理する。

なぜ今、この3つのプロトコルを理解する必要があるのか

オンプレ環境では、認証の仕組みはシステムの奥深くに隠れていた。ドメイン参加したWindowsクライアントがActive DirectoryにKerberosで認証し、ファイルサーバーやSharePointへシームレスにアクセスする。エンジニアが個々のプロトコルを直接意識する場面は多くなかった。

クラウド移行が進むと、事情が変わる。

・AWSマネジメントコンソールへのSSO: 社員全員分のIAMユーザーを作らず、既存のActive Directory経由でログインさせたい
・マイクロサービスのAPI認証: サービスA→サービスBへのリクエストで「誰が呼んでいるか」を安全に検証したい
・GitHub ActionsからAWSへのデプロイ: アクセスキーを使わずにCI/CDを安全に実行したい
・マルチクラウド環境のユーザー管理一元化: Entra IDを軸にAWS・GCPにもSSOしたい

こうしたシナリオに取り組むたびに、SAMLとOIDCとOAuth 2.0が入り混じる設計書や公式ドキュメントに直面する。3つを整理できると、設計の選択肢が格段に広がる。

まず30秒で整理する：3つのプロトコルの位置づけ

細かい仕様に入る前に、全体像をつかもう。

ここで押さえておきたい重要な点がある。OAuth 2.0は「認証（Authentication）」の仕様ではない。「誰かが許可した範囲でリソースにアクセスできる権限を委任する」ための仕様だ。ユーザーが誰かを確認するには、OIDCかSAMLが必要になる。

認証と認可の概念的な違いについては別記事でも詳しく解説しているので、合わせて参照してほしい。

OAuth 2.0とは？「認可」のためのフレームワーク

OAuth 2.0（RFC 6749）は2012年に標準化された認可のフレームワークだ。

具体的には「あなたのGoogleドライブにアクセスするため、このアプリに許可を与えますか？」というフローを標準化したもの。ユーザーが「Yes」を押すと、アプリはGoogleからアクセストークンを受け取り、それを使ってAPIを呼び出せる。重要なのは「アプリ側はユーザーのパスワードを知らなくてよい」点だ。

クラウドインフラでよく使われるOAuth 2.0フローを整理すると、次の通りだ。

OAuth 2.0単体で「ユーザーが誰か」を知りたい場合、アクセストークンの中身を独自解釈するしかなく、相互運用性が失われる。その問題を解決したのがOIDCだ。

SAML 2.0とは？エンタープライズSSOの定番標準

SAML 2.0（Security Assertion Markup Language）は2005年に標準化されたXMLベースの認証・SSO標準だ。長い歴史を持ち、Active Directory Federation Services（ADFS）をはじめ多くのエンタープライズIdPが対応している。

SAML 2.0の主要な登場人物を整理する。

・IdP（Identity Provider）: ユーザーを認証し、SAMLアサーションを発行する側。Microsoft Entra ID、ADFS、Okta、OneLoginなど
・SP（Service Provider）: IdPが発行したアサーションを信頼してサービスを提供する側。AWSマネジメントコンソール、Salesforce、Google Workspaceなど
・SAMLアサーション: IdPがSPに送るXML形式の証明書。「このユーザーはAさんで、ロールはAdminです」という情報を電子署名付きで含む

SAML 2.0の典型的な利用フロー（SP-Initiated）はこうなる。

# 1. ユーザーがSPのURL（例: AWSコンソール）にアクセス
# 2. SPはSAML AuthnRequestを生成し、ユーザーをIdPにリダイレクト
# 3. ユーザーはIdP（例: Entra ID）でログイン
# 4. IdPはSAMLアサーション（XML）を生成し、ブラウザ経由でSPにPOST
# 5. SPはアサーションの署名を検証し、ユーザーをログイン状態にする

SAML 2.0の強みと弱みを整理すると次の通りだ。

・強み: 歴史が長く、企業向けSaaS（Salesforce・Workday・ServiceNow等）の対応率が高い。既存ADFSとの統合実績が豊富
・弱み: XMLパースが複雑で設定ミスが起きやすい。モバイルアプリやAPIには向かない（ブラウザのリダイレクトを前提とした設計のため）

オンプレActive DirectoryとAWS/Azureを最小コストで連携させたい場合、SAMLが引き続き第一候補になる。

OpenID Connect（OIDC）とは？OAuth 2.0の上に乗った認証仕様

OpenID Connect（OIDC）は2014年にリリースされたOAuth 2.0の拡張仕様だ。OAuth 2.0が認可しかカバーしていない弱点を補い、「誰がログインしているか」を標準化された方法で証明できるようにした。

OIDCが追加したキーコンセプトは3つある。

・IDトークン（id_token）: JWTフォーマットで発行される。中にsub（ユーザーID）・email・nameなどのクレームが含まれ、署名検証により改ざん検出できる
・userinfo エンドポイント: アクセストークンを使って追加のユーザー情報を取得できるREST API
・Discovery Document: /.well-known/openid-configuration にアクセスすると、IdPのエンドポイント一覧や公開鍵情報が自動取得できる。設定の自動化に役立つ

OIDCのIDトークン（JWT）はJSONで読みやすく、モバイルアプリやSPAでも扱いやすい。SAMLのXMLアサーションと比べると、実装の難易度が大幅に下がる。

SAMLアサーションとOIDC IDトークンの形式を比較すると、次のようなイメージだ。

# SAML アサーション（簡略イメージ）
# <samlp:Response>
#   <saml:Assertion>
#     <saml:Subject>
#       <saml:NameID>alice@example.com</saml:NameID>
#     </saml:Subject>
#     <saml:AttributeStatement>
#       <saml:Attribute Name="Role">Admin</saml:Attribute>
#     </saml:AttributeStatement>
#   </saml:Assertion>
# </samlp:Response>

# OIDC IDトークン（JWT デコード後のペイロード イメージ）
# {
#   "iss": "https://login.microsoftonline.com/{tenant-id}/v2.0",
#   "sub": "alice",
#   "email": "alice@example.com",
#   "roles": ["Admin"],
#   "exp": 1728345600
# }

実務での使い分け：どのプロトコルをいつ選ぶか

3つのプロトコルの違いがわかったところで、実際の選定基準を整理しよう。

現場でよく聞く話として「モダンだからすべてOIDCに移行すべき」という意見がある。しかし既存のSAML IdPが安定して動いており、移行コストが大きい場合はSAMLを継続するのが合理的な判断だ。新規システムや既存インフラとの依存が少ない場合にOIDCを採用するというスタンスが、現実的な落とし所になることが多い。

AWS・Azureでの実装シナリオ（想定例）

1. AWS IAM Identity CenterとEntra IDのOIDC連携

想定例として、社員が数百名規模の法人（架空）がEntra IDを社内IdPとして、AWS IAM Identity CenterにExternal IdPとしてOIDCで接続したケースを考えてみよう。

AWS IAM Identity CenterはSCIM 2.0（ユーザープロビジョニング）とOIDCの両方をサポートしている。この構成では、社員がEntra IDにログインするだけでAWSコンソールへの権限付きSSOが実現する。

・メリット: ユーザー追加・削除はEntra ID側で一元管理。人事システム連携でオンボード・オフボードを自動化しやすい
・注意点: Entra IDのアプリケーション登録で「Enterprise Application」としてAWS IAM Identity Centerを追加するとき、メタデータURLの設定を誤るとフェデレーションが失敗する。Discovery DocumentのURLは https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration から確認できる（2026年10月時点）

Microsoft Entra IDの詳細な設定については別記事を参照してほしい。

2. IAM SAMLフェデレーション（オンプレADFS連携）

オンプレにADFSが存在する場合、IAMのSAMLフェデレーション機能でAWSコンソールへのSSOを実現できる。大まかな手順はこうなる。

# AWS CLI: IAM SAMLプロバイダー作成
aws iam create-saml-provider \
  --saml-metadata-document file://adfs-metadata.xml \
  --name MyADFSProvider

# IAMロール作成（ADFSユーザーがAssumeできるロール）
# 信頼ポリシーのPrincipalに上記SAMLプロバイダーARNを指定する

ADFSのRelying Party TrustにAWSのSAMLメタデータURLを設定し、クレームルールでRoleとRoleSessionNameを発行するよう構成する。クレームルールの設定ミスは「アクセス権限がありません」エラーとして表れるため、ADFS側のデバッグログと合わせて確認するのが定石だ。

3. Amazon CognitoとOIDCによるアプリ認証

Amazon CognitoはOIDCに準拠したUser Poolsを提供している。自社WebアプリのユーザーログインをCognito User Poolで管理し、IDプール（Identity Pool）でAWS一時認証情報に交換する構成は、サーバーレスAPIの認証によく使われる。

Cognito User Poolsが発行するIDトークンをAPI GatewayのCognito Authorizerに渡すことで、Lambda関数を呼び出す前に認証を済ませられる。この仕組みを正確に設計するには、OIDCのIDトークン（JWT）のクレーム構造を理解しておくことが前提条件になる。

よくある誤解とつまずきポイント

【よくある誤解1】「OAuth 2.0でログイン」という表現

「GoogleアカウントでOAuthログインする」というUIをよく見かけるが、技術的には正確ではない。ユーザー認証を行っているのはOIDCのIDトークン部分だ。OAuth 2.0は認可の仕組みにすぎず、「誰がログインしているか」を証明するのはOIDCが担っている。この区別を誤解したまま設計すると、認証情報をアクセストークンに頼った脆弱な実装になりやすい。

【よくある誤解2】「SAMLはもう古いから使うべきでない」

エンタープライズSaaSや多くのIdPがSAMLに対応しており、特にADFSベースのオンプレ環境ではSAMLが最も安定した選択肢だ。OIDCへの移行は計画的に行うべきであり、「新しいから」という理由だけで既存の安定したSAML連携を置き換えることは合理的でない。

【よくある誤解3】「JWTとOIDCは同じもの」

JWTはトークンの形式（JSON Web Token）であり、OIDCで使われるIDトークンの実装形式の一つだ。JWTはOIDC専用ではなく、OAuth 2.0のアクセストークンもJWT形式で発行されることがある。「JWTを使っているからOIDCだ」という思い込みには注意が必要だ。

【一般的なつまずき】SAMLアサーションの署名検証失敗

IdP証明書のローテーション時に署名検証が失敗し、SSOが突然止まる事象は広く知られたつまずきだ。SPは定期的にIdPのメタデータを更新する仕組みを持たせておくことが重要で、AWS IAM SAMLプロバイダーも同様に、IdP証明書更新時は update-saml-provider コマンドでメタデータを差し替える必要がある。

本記事のまとめ

3つのプロトコルを一言で整理すると次のようになる。

・OAuth 2.0: 認可のフレームワーク。単独では認証に使えないが、Client Credentials FlowでM2M認証に使われる
・SAML 2.0: 2005年標準化のXMLベース認証・SSO。エンタープライズSaaSとオンプレAD連携の定番
・OIDC: OAuth 2.0の上に認証を追加した2014年の仕様。JWTのIDトークンで現代的なSSO・API認証を実現

選定の大原則はシンプルだ。既存ADFSやエンタープライズSaaSとのSSO構築ならSAML、新規のモバイル・API・SPA・CI/CDパイプライン認証ならOIDC、バックエンドのサービス間通信ならOAuth 2.0 Client Credentialsを選ぶ。

クラウドのIAM設計は、このプロトコル選定の正確な理解が土台になる。認証と認可の違いの理解と合わせてぜひ参照してほしい。