SSO設計の前提：SAML/OIDCの基本をそろえる

連携の土台：IdPとSP/RP、アサーションとトークン

SSOは、利用者の身元を証明する側（IdP＝Identity Provider）と、その証明を受け取って利用者を認識する側（SAMLではSP＝Service Provider、OIDCではRP＝Relying Party）が「信頼関係」を結ぶことで成り立ちます。技術的には、IdPが「認証した事実やユーザー属性」をアサーションやトークンにして発行し、それをSPやRPが検証することでログインが成立します。

大切なのは、SAMLかOIDCかというプロトコルの違いがあっても、根本的な考え方は共通しているということです。NISTが公開しているフェデレーション指針でも「誰が、どの条件で認証し、その保証レベル（AAL）がどこまでか」を明確にして接続することが推奨されています。もしこの点を曖昧にしたまま複数のアプリやサービスにSSO接続を広げると、後で統合や監査が難しくなり、混乱の原因になります。

SAMLとは：XMLアサーションで“認証の事実”を渡す

SAML（Security Assertion Markup Language）2.0は、XMLで記述されたアサーションをやり取りする方式です。アサーションには「認証の事実」「ユーザー属性」「認可情報」などが含まれ、HTTP RedirectやPOST、SOAPなどのバインディングを通じて受け渡されます。

SAMLは大企業や公共機関の基幹システムで広く使われており、ブラウザベースのSSOやシングルログアウト（SLO）が標準プロファイルとして整備されています。多くの人事システムや会計SaaSにSAMLコネクタが豊富に用意されているため、既存資産を活かしやすいのが強みです。

技術面では、アサーション署名や条件（NotBefore/NotOnOrAfter）、オーディエンス制約を活用して「なりすまし」や「不正利用」を防ぐ仕組みが整っています。ただしXMLをベースとするため、開発やデバッグは多少複雑になりがちです。

出典：OASIS「SAML 2.0 Core」

OIDCとは：OAuth 2.0の上に載る“IDレイヤー”

OIDC（OpenID Connect）は、OAuth 2.0の上に「IDトークン（JWT形式）」を追加した認証プロトコルです。クライアントは認可コードフロー（PKCEを含む）でIDトークンを取得し、その署名・発行者（iss）・受信者（aud）などを検証して本人確認を行います。

OIDCの特徴は「必要な属性を必要な分だけ安全にやり取りできる」点です。スコープやクレームを指定すれば、メールアドレスや氏名など必要な情報だけを取得できます。JSONベースのため、REST APIやモバイルアプリ、SPA（シングルページアプリ）との親和性が高く、近年のモダン開発で主流になっています。

出典：OpenID Foundation「OpenID Connect Core 1.0」
出典：IETF「RFC 6749 OAuth 2.0」

SAML/OIDCの“違い”を短く押さえる（形式／フロー／使い所）

形式と中身：XMLアサーションか、JWTか

SAMLではXML署名つきアサーションをやり取りし、ユーザー属性もXMLの要素として記載されます。OIDCではJSON Web Token（JWT）を使い、ヘッダー・ペイロード・署名の3部構成で認証情報を渡します。ペイロードにはiss（発行者）、aud（受信者）、exp（有効期限）などが含まれ、これを検証して正当性を確認します。

JSONやREST APIに慣れている開発チームにとってはOIDCの方が取り回しやすいですが、XMLベースの統合基盤を持つ企業にはSAMLが自然にフィットします。

出典：OASIS「SAML 2.0 Tech Overview」

フローの違い：ブラウザSSO中心か、OAuthフロー拡張か

SAMLはブラウザを介したSSOに最適化されており、Webアプリ向けのシナリオに強みがあります。一方でOIDCはOAuth 2.0のフロー（特に認可コード＋PKCE）を前提にしているため、SPAやモバイルアプリ、API連携まで一貫して利用できます。

そのため、従来型の社内SaaSや人事系アプリではSAMLが適しており、モバイルやAPI連携を視野に入れる場合にはOIDCの方が将来的に拡張しやすいという棲み分けになります。

出典：IETF「RFC 6749 OAuth 2.0」

使い分けの感覚：エンタープライズSaaS⇔モバイル/API

実務では「SAMLはエンタープライズSaaSに強く、OIDCはモバイルやAPI連携に強い」という傾向が見られます。OktaやAuth0のガイドでも、「OAuthは権限移譲、SAMLとOIDCは認証、OIDCはモダンアプリで使いやすい」という整理が一貫して示されています。

したがって、新規開発のアプリケーションやAPI基盤はOIDCを第一候補としつつ、既存の大規模SaaSや基幹連携についてはSAMLを維持するのが現実的な判断となります。

出典：Okta「OAuth / OIDC / SAML の違い」
出典：Auth0「SAML vs OpenID Connect」

設計ルール：どちらを選ぶか、属性はどう渡すか、移行はどう進めるか

プロトコル選定チェックリスト（アプリの型・連携先・将来像）

SSO設計指南（SAML/OIDC 違い）を検討するうえで、まず必要なのは「対象アプリの種類」「既存の接続先サービスの対応状況」「将来の拡張性」を整理することです。

たとえばブラウザ中心の社内ポータルならSAMLで十分なことが多いですが、モバイルアプリやSPA、API基盤まで含むとOIDCの方が自然に設計を一本化できます。一方で、人事・会計など既存のSaaSはSAMLコネクタが充実しているため、切り替えは難しいのが現実です。

そのため「既存はSAMLを維持し、新規はOIDCを採用する」という二重構成が妥当になります。これを支えるには、IdPが両方のプロトコルを扱えるようにしておくのが安全です。チェックリストとしては「アプリの型／既存SaaSの対応／将来のAPI戦略」を最低限並べて確認するのが効果的です。

属性連携の設計：SAML属性⇔OIDCクレームの対応表を作る

SAMLはXMLの属性、OIDCはJSONのクレーム（claims）でユーザー情報をやり取りします。表現方法は違いますが、原則は同じで「必要最小限だけ渡すこと」が重要です。

実務では「SAML属性名とOIDCクレーム名の対応表」を作り、承認フローにのせる運用にすると安全です。過剰な個人情報を流すことを防ぎ、後の監査でも説明しやすくなります。特にNISTのガイドラインでは、最小共有（minimum disclosure）の原則が繰り返し強調されており、設計段階からの配慮が必須です。

段階的移行：ブリッジ／二重実装／順次切替

既存のSAML環境を持つ組織がOIDCに移行する際は、一気に切り替えるのではなく段階的に進めるのが現実的です。

最も安定するのは「SAMLとOIDCを二重に提供し、順次切替えていく」方法です。新規アプリはOIDCへ接続し、既存はSAMLのまま残しつつ、期限を区切って移行していきます。ブリッジ（SAML⇔OIDC変換）を長期利用するのは複雑化の原因になるため避けた方がよいでしょう。

この移行中は「どのアプリがSAMLか、OIDCか」を必ず台帳で管理します。また、OIDCのIDトークン検証（署名、iss、aud、exp、nonce、JWKsの取得など）は必ず自動化し、ベンダーの推奨ガイドに沿って運用するのが事故防止につながります。

出典：Microsoft Entra「OIDC on the Microsoft identity platform」
出典：NIST SP 800-63C「Federation and Assertions」
出典：OpenID Foundation「OpenID Connect Core 1.0」

セキュリティと運用：署名・MFA・セッション/ログアウト

署名と暗号化：検証“必須項目”を運用で固定する

SAMLでもOIDCでも、セキュリティの肝は「署名と暗号化を正しく検証すること」です。

SAMLではアサーションの署名と暗号化を確認し、有効期限（NotOnOrAfter）やオーディエンス制約を必ず検証します。OIDCではIDトークン（JWT）の署名検証を自動化し、発行者（iss）、受信者（aud）、有効期限（exp）、nonceのチェックを行います。さらに、JWKsの鍵ローテーションに自動追随できるように設計します。TLSは当然の前提であり、証明書や鍵の入替手順もCI/CDに組み込むと堅牢です。

認証強度（AAL）とMFA：“本人確認の強さ”を切り替えられる設計

安全性を高めるためには、単にSAMLかOIDCかを選ぶだけでは不十分です。NIST 800-63Bが示すAAL（Authentication Assurance Level）の考え方に従い、操作内容に応じて本人確認の強度を切り替えられるようにします。

例えば通常のログインはAAL1でも、送金や重要な権限変更はAAL2以上を必須にする、といった設計です。MFA（多要素認証）をIdP側の設定で追加できるようにしておくと、アプリ改修なしで認証強度を上げられるため、運用効率が高まります。

ログアウト（SLO/Sessions）：方式の違いを前提設計に織り込む

ログアウトの扱いはSSO設計指南（SAML/OIDC 違い）の中でも実装上の難所です。

SAMLはシングルログアウト（SLO）のプロファイルがあり、IdPとSP間で連動できますが、実装差が大きく不具合が起きやすいのが課題です。一方OIDCはRP発ログアウト（end_session_endpoint）やフロント／バックチャネルログアウトの仕組みが整備されており、モダンアプリにはこちらの方が適しています。

どちらを選ぶにしても、まずは「ユーザーにどのようなログアウト体験を提供したいか」を先に決め、それに基づいてプロトコルを選択することが重要です。

出典：OASIS「SAML 2.0 Core」
出典：OpenID Foundation「RP-Initiated Logout」
出典：Microsoft Entra「SAML Single Sign-Out」
出典：NIST SP 800-63B-4「Authentication and Authenticator Management」

導入テンプレ：要件整理→接続→検証の“最小パック”

要件整理テンプレ：スコープ・属性・保証レベル

SSO設計指南（SAML/OIDC 違い）を検討する際、最初に必要なのは「要件を1枚で整理すること」です。誰がどのアプリでSSOを利用するのか（ユーザー範囲）、どの属性が必要なのか（氏名、メール、所属など）、どの認証強度（AAL）を求めるのかをまとめます。

SAMLであれば「必要な属性名とNameFormat」を書き、OIDCであれば「必要なスコープ（openid email profile など）とクレーム」を明記します。また、アプリ側が保持してよいデータの範囲や保存期間も書き添えると、監査の場でも迷わず説明できるようになります。

接続手順テンプレ：メタデータ⇔ディスカバリー

接続の流れも両者で少し違います。SAMLではIdPとSPが「メタデータ」（エンドポイント、証明書、NameIDなど）を交換して接続を確立します。OIDCでは「ディスカバリー」（/.well-known/openid-configuration）を通じてエンドポイントや鍵（JWKs）を取得し、認可コード＋PKCEでIDトークンを取得して検証します。

どちらにしても、運用上は「時計合わせ（NTPによる時刻同期）」「証明書更新の自動反映」「aud（オーディエンス）の管理」をランブックに落としておく必要があります。これを怠ると、突発的な認証エラーで利用者がログインできなくなる事故につながります。

検証テンプレ：正当性・期限・オーディエンス

導入時の結合テストでは、SAMLなら署名検証や有効期限（NotBefore/NotOnOrAfter）、オーディエンス制約、属性マッピングの確認が必須です。OIDCならIDトークンの署名、iss/aud/exp/nonceなどのチェック、JWKs取得失敗時の挙動確認が欠かせません。さらに、負荷テストや多重ログイン、ログアウトの連動なども見ておくと安全です。

検証の観点は「誰が見ても同じ結論になるように文章化」して残します。単なる動作確認で終わらせず、合格基準と理由をセットで記録しておくことで、後のトラブル時の説明責任が果たしやすくなります。

出典：NIST SP 800-63C「Federation and Assertions」
出典：OpenID Foundation「OpenID Connect Core 1.0」
出典：OASIS「SAML 2.0 Core」
出典：Curity.io「OIDCテストと検証のベストプラクティス」

まとめ：SSO設計は“いまSAML＋これからOIDC”を前提に最適化する

SSOの設計は「SAMLとOIDCどちらが正解か」ではなく、「両者をどう共存させ、将来的にどう移行するか」が本質です。

SAMLはエンタープライズSaaSとの親和性が高く、既に導入されている資産も豊富です。一方で、OIDCはモバイルアプリやSPA、API基盤との相性が良く、今後の拡張性を考えた場合の第一候補となります。したがって「既存はSAMLを尊重しつつ、新規はOIDCで構築する」という二重対応が現実解です。

設計の実務では、SAML属性とOIDCクレームのマッピング表を整備し、段階的な移行ルートを明示しておくことが重要です。また、AALに基づく認証強度の運用、MFAによるステップアップ認証、ログアウト体験の設計方針などを先に決めることで、システム全体の整合性を維持できます。

さらに、出典で示したようにSAML/OIDCの仕様書や国際標準を基準に据え、検証観点や合格基準を固定化すれば、運用が属人的にならず「再現性のあるSSO」を実現できます。更新と監査を定期的に回しながら、「いまSAML、これからOIDC」という道筋をチーム全体で共有することが、迷いのない設計と安全な運用につながります。

出典：NIST SP 800-63C「Federation and Assertions」
出典：OpenID Foundation「OpenID Connect Core 1.0」
出典：OASIS「SAML 2.0 Core」
出典：Okta「OAuth / OIDC / SAML の違い」