フェデレーションID：SAML、OAuth、OpenID Connect

現代のエンタープライズ環境では、従業員はクラウドアプリ、SaaSツール、パートナーポータル、社内システムなど、数多くのアプリケーションにアクセスする必要があります。これらはそれぞれ異なる組織によって管理されている場合があります。アプリケーションごとに個別のアカウントを作成・管理する方法は、安全性が低く（認証情報が増えすぎるため）、効率的でもありません。フェデレーションIDは、Identity Provider（IdP）（信頼できる権威あるID情報のソース）がユーザーを認証し、その認証済みIDを組織の境界を越えてService Provider（SP）と共有できるようにすることで、この問題を解決します。ユーザーは一度認証するだけで、認証情報を再入力せずに複数のシステムへアクセスできます。

シングルサインオン（SSO）を使用すると、ユーザーは一度認証するだけで、セッション中に再認証することなく複数のアプリケーションへアクセスできます。ユーザーはIdentity Provider（企業のActive Directory、Okta、Azure AD）にログインし、セッショントークンまたはアサーションを受け取り、アクセスする各Service Providerにそのトークンを提示します。SSOは、ユーザーが管理する必要のあるパスワードの数を減らして（使い回しも減らします）、認証ポリシーを一元的に適用できるようにし、IdPレベルでアカウントを無効化した際には、統合されたすべてのアプリケーションから直ちにアクセスを取り消せるため、セキュリティを向上させます。

SAML（Security Assertion Markup Language）2.0は、Identity ProviderとService Providerの間で認証データおよび認可データを交換するための、XMLベースのオープン標準です。SAMLのフローは次のとおりです。(1) ユーザーがService Provider（例：Salesforce）にアクセスします。(2) SPがIdentity Provider（例：Okta）へリダイレクトします。(3) ユーザーがIdPで認証します。(4) IdPが、ユーザーのIDと属性を含む署名済みXMLのSAMLアサーションを発行します。(5) アサーションがSPに返されます。(6) SPがIdPの公開鍵を使用してアサーションの署名を検証し、アクセスを許可します。SAMLは、WebアプリケーションのエンタープライズSSOで広く使用されています。

SAMLフェデレーションには、3者が関与します。プリンシパルは、アクセスを求めるユーザー（またはシステム）であり、認証プロセスを開始します。Identity Provider（IdP）は、プリンシパルを認証してアサーションを発行する、権威あるID情報のソースです。例としてMicrosoft Azure AD、Okta、Ping Identity、ADFSがあります。Service Provider（SP）はアサーションを受け取り、それに基づいてアクセスを許可します。例としてSalesforce、Google Workspace、AWS、およびSAML対応アプリケーションがあります。SPとIdPは、互いのエンドポイントURLと署名証明書を含むメタデータを事前に交換して、信頼関係を確立します。

OAuth 2.0は、ユーザーの認証情報を公開せずに、サードパーティアプリケーションがユーザーに代わってリソースへアクセスできるようにする認可フレームワークです（認証プロトコルではありません）。典型的な使用例は、「この写真編集アプリにGoogleフォトへのアクセスを許可しますか」です。OAuth 2.0には、Resource Owner（ユーザー）、Client（サードパーティアプリ）、Authorization Server（トークンを発行）、Resource Server（保護されたリソースをホスト）という4つのロールがあります。ユーザーがクライアントを認可すると、クライアントはアクセストークンを受け取り、それをResource Serverに提示します。ユーザーの実際のパスワードを知る必要はありません。

認可コードフローは、Webアプリケーションで使用できるOAuth 2.0フローの中で最も安全なものです。フローは次のとおりです。(1) クライアントが、要求するスコープを付けてユーザーをAuthorization Serverへリダイレクトします。(2) ユーザーがAuthorization Serverで認証し、同意します。(3) Authorization Serverが、短時間だけ有効な認可コードを付けてユーザーをリダイレクトします。(4) クライアントが、クライアント認証情報を使用したサーバー間通信によって、コードをアクセストークン（オプションでリフレッシュトークンも）と交換します。(5) クライアントがアクセストークンを使用してResource Serverを呼び出します。コードの交換はサーバー側で行われるため、アクセストークンがブラウザーの履歴やログに露出することを防げます。

OpenID Connect（OIDC）は、OAuth 2.0上に構築された認証レイヤーです。OAuthが提供するのは認可だけです（アクセストークンによってクライアントが実行できることを証明します）。一方、OIDCは認証を追加し、IDトークンによってユーザーが誰であるかを証明します。OIDCはOAuthフローにopenidスコープを追加し、アクセストークンとともに署名済みのJWT（JSON Web Token）IDトークンを返します。IDトークンには、ユーザーを識別するクレーム（name、email、sub［subject identifier］）が含まれます。OIDCは現在、コンシューマー向けSSOで主流のプロトコルです。「Sign in with Google/Apple/Microsoft」ボタンはすべてOIDCを使用しています。

JSON Web Token（JWT）は、当事者間でクレームを表現するための、コンパクトでURLセーフな形式です。JWTは、base64urlでエンコードされた3つの部分をドットで区切った構造になっています。Header（アルゴリズムとトークン種別）、Payload（iss、sub、aud、exp、iat、およびカスタムクレームなどのクレーム）、Signature（トークンの完全性を検証する暗号学的署名）です。JWTは自己完結型であるため、Resource ServerはAuthorization Serverに問い合わせなくても検証でき、パフォーマンスが向上し、ステートレスアーキテクチャが可能になります。重要なセキュリティ要件は、JWTの署名を必ず検証し、exp（有効期限）とaud（対象者）のクレームを確認することです。

各標準をどの場面で使用するかを理解することは、Security+試験において非常に重要です。SAML 2.0：Webアプリケーション向けのエンタープライズSSOで、ブラウザー経由のフローとXMLアサーションを使用します。古い技術ですが、エンタープライズ環境で広く導入されています。OAuth 2.0：API認可に使用し、サードパーティアプリにリソースへの限定的なアクセスを許可します。ユーザーを直接認証するものではありません。OIDC：OAuth 2.0上に構築された、コンシューマー向けおよび最新のエンタープライズ認証（SSO）に使用されます。ユーザーを識別するJWT IDトークンを返します。実際には、エンタープライズ環境ではアプリケーションSSOにSAMLを、APIやモバイルの認証にOIDCを使用することがよくあります。最新のクラウドネイティブ環境では、JSON/JWT形式でモバイル対応にも優れていることから、SAMLよりOIDCが好まれます。

フェデレーションIDシステムには、固有の攻撃ベクトルがあります。アサーションリプレイ攻撃：攻撃者がSAMLアサーションを傍受し、再送してアクセスを取得します。アサーションの有効期間を短くし、1回限り使用するアサーションIDを用いることで軽減できます。XML署名ラッピング（XSW）：SAMLでは、攻撃者が署名済みXMLを操作し、元のコンテンツに対する署名を有効なままにしてクレームを変更できる場合があります。JWTアルゴリズム混同：サーバーがRS256（非対称）とHS256（対称）の両方のアルゴリズムを受け入れる場合、攻撃者はサーバーの公開鍵をHS256のHMACシークレットとして使用してJWTを偽造できます。アルゴリズムのヘッダーが想定されるアルゴリズムと一致することを必ず検証してください。オープンリダイレクター：リダイレクトによって攻撃者が管理するサイトへトークンが窃取されるのを防ぐため、OAuthのリダイレクトURIは完全一致で検証する必要があります。

エンタープライズIDフェデレーションでは、システム間でユーザーIDデータを同期する必要があることがよくあります。SCIM（System for Cross-domain Identity Management）は、Identity Providerと接続されたService Providerの間で、ユーザーのプロビジョニングとデプロビジョニングを自動化するためのREST API標準です。新しい従業員がAzure AD（IdP）に追加されると、SCIMによってSalesforce、Slack、GitHubなど、SCIM互換アプリにその従業員のアカウントが自動的に作成されます。従業員が退職すると、SCIMはすべてのアカウントを同時に無効化します。これにより、休眠アカウントが悪用される可能性のある期間をなくせます。SCIMは、SSOプロトコル（SAML/OIDC）が扱わないライフサイクル管理を担うことで、SSOプロトコルを補完します。

このレッスンでは、次のことを学びました。SAML 2.0は、エンタープライズ環境でブラウザーを介したSSOを実現するためにXMLアサーションを使用します。OAuth 2.0は、APIアクセスの委任に使用する認可フレームワークです。OpenID Connectは、OAuth上に認証（JWT IDトークン）を追加します。SCIMは、フェデレーションシステム間のIDライフサイクル管理を自動化します。これで認証と認可のコースは完了です。次はネットワークセキュリティの基礎について説明します。