シングルサインオン
シングルサインオン（SSO）では、ユーザーが1つのアプリケーションにログインすると、使用しているプラットフォーム・テクノロジー・ドメインの種類に関係なく、他のアプリケーションにも自動的にサインインされます。ユーザーは1回しかサインインしないため、このような名称（シングルサインオン）で呼ばれています。
たとえば、GmailなどのGoogleサービスにログインしたユーザーは、自動的にYouTube、AdSense、Google AnalyticsといったGoogleアプリに認証されます。同様に、GmailなどのGoogleアプリからログアウトすると、自動的にすべてのGoogleアプリからログアウトされます。これを、シングルログアウトと言います。
SSOは、アプリケーションやサービスを使用するユーザーに、シームレスなエクスペリエンスを提供します。ユーザーは、アプリケーション・サービス別に資格情報を覚えておかなくても、一度ログインするだけですべてのアプリケーションにアクセスできます。
ユーザーが認証を必要とするドメインにアクセスすると、必ず認証ドメインにリダイレクトされ、ログインが求められます。ユーザーが認証ドメインにログイン済みの場合には、再度サインインを求めることなく、即座に元のドメインにリダイレクトできます。
仕組み
シングルサインオンとシングルログアウトはセッションを使って実現されます。SSOでは、ユーザーに最大3つの異なるセッションが関与します。
アプリケーションが管理するローカルセッション
認可サーバーセッション（SSOが有効化されている場合）
IDプロバイダー（IdP）セッション（ユーザーがGoogleやFacebook、エンタープライズSAML IDプロバイダーなどのIDプロバイダーを通してログインした場合）
SSOの場合は中心となるドメインが認証を行い、そのセッションを他のドメインと共有します。セッションの共有方法はSSOプロトコル間で異なりますが、一般的な概念は同じです。
たとえば、認証ドメインが署名済みのJSON Web Token （JWT）（JSON Web Encryption（JWE）で暗号化）を生成することもあります。これには、認証を必要とする他のドメインのユーザーを識別するために必要なすべての情報が含まれます。このトークンはクライアントに渡されますが、署名付きであるため、クライアントが変更を加えることはできません。トークンは、リダイレクトによって元のドメインに渡されたり、認証ドメインや他のドメインによってユーザーの本人確認のために使用されたりします。
ユニバーサルログインを使ったSSO
シングルサインオン（SSO）とAuth0を手軽で最も安全に実装するには、認証にユニバーサルログインを使用します。実際、アプリケーションがユニバーサルログインを使用している場合、現在のSSOの実装は、ネイティブプラットフォーム（iOSやAndroidなど）でのみ可能です。SwiftとAndroidのクイックスタートには、ユニバーサルログインの使用例が紹介されています。
アプリケーションでユニバーサルログインを使用できない場合は、埋め込み認証について、以下の追加情報を確認してください。
初回ログイン時のSSO
Auth0を使用したSSOの場合、中央サービスはAuth0認可サーバーです。
ユーザーが初めてログインする際のSSOフローの例を見てみましょう。
アプリケーションがユーザーをログインページへリダイレクトします。
Auth0が、SSOクッキーの存在を確認します。
ユーザーは、初めてログインページを訪問していてSSOのクッキーがないため、構成した接続の1つを使ってログインするよう求められます。
ユーザーがログインすると、Auth0がSSOのクッキーを設定してユーザーをアプリケーションへリダイレクトし、ユーザーの身元情報を含んだIDトークンを返します。
以降のログイン時のSSO
ユーザーが再びWebサイトに戻ってきたときのSSOフローの例を見てみましょう。
アプリケーションがユーザーをログインページへリダイレクトします。
Auth0が、SSOクッキーの存在を確認します。
Auth0がSSOのクッキーを見つけ、必要であれば更新します。ログイン画面は表示されません。
Auth0がユーザーをアプリケーションへリダイレクトし、ユーザーの身元情報を含んだIDトークンを返します。
ユーザーのSSOのステータスを確認する
auth0.js SDKのcheckSessionメソッドを呼び出すと、アプリケーションからユーザーのSSOステータスを確認することができます。このメソッドはiframe内でユーザーを暗黙に認証しようとします。認証が成功するかどうかは、ユーザーに有効なSSOのクッキーがあるかどうかによって決まります。
プロトコル
SAMLとWS-Federation
Security Assertion Markup Language（SAML）とWebサービスフェデレーション（WS-Fed）はどちらもSSOの実装に広く使用されているプロトコルです。SAMLとWS-Fedは、どちらもXML形式の認可・認証データを交換します。主要な部分は、ユーザー・IDプロバイダー・サービスプロバイダーです。
SAMLまたはWS-Fedでは：
ユーザーがサービスプロバイダーからのリソースを要求します。
サービスプロバイダーは、ユーザーにリソースへのアクセスを許可すべきか、IDプロバイダーに確認を取ります。
IDプロバイダーは、ユーザーの身元を検証し、有効であれば、ユーザーによるアクセスを許可するようサービスプロバイダーに伝えます。
OpenID Connect
OpenID Connect（OIDC）は、消費者向けのSSO実装で広く使用されている認証プロトコルです。OIDCプロトコルは、JSON Web Tokenと中央IDプロバイダーを介して認証を処理します。
OIDCでは：
ユーザーがアプリケーションへのアクセスを要求します。
アプリケーションは、認証のためにユーザーをIDプロバイダーへリダイレクトします。
IDプロバイダーはユーザーを検証し、成功すると、ユーザーにアプリケーションへのデータアクセス権を付与するよう求めます。
アクセス権が付与されると、IDプロバイダーは、IDトークンを生成します。このトークンには、アプリケーションが使用できるユーザー身元情報が含まれます。
IDプロバイダーがユーザーをアプリケーションへ戻します。
AD/LDAP
Lightweight Directory Access Protocol（LDAP）は、複数のアプリケーションで共有できる資格情報のディレクトリにアクセスするためのアプリケーションプトロコルで、イントラネットで広く使用されています。Active Directory（AD）と併用することでユーザーIDの一元管理が可能になり、アプリケーションはLDAP/ADサーバーに認証要求を送信するようになります。LDAPプロトコルは、LDAP Data Interchange Format（LDIF）で情報を交換します。
SP起点のSSO
SP-initiated SSOでは、Auth0がSSOサービスプロバイダー（SP）になります。
ユーザーがアプリケーションにログインすると：
アプリケーションがユーザーに1つ以上の外部IDプロバイダーを提示します。
ユーザーが認証に使用するIDプロバイダーを選択してログインします。
認証が成功すると、ユーザーがアプリケーションへ戻されます。
Auth0では、SP起点のSSOは接続別に処理されます。
IdP起点のSSO
IdP起点SSOでは、サードパーティーのIDプロバイダー（IdP）がSSOプロバイダーになります。
ユーザーがアプリケーションにログインすると：
アプリケーションがユーザーをIDプロバイダーにリダイレクトします。
サードパーティのIDプロバイダーが認証と認可を行います。
認証が成功すると、ユーザーがアプリケーションへ戻されます。
IdP起点SSOの実装を計画するときに、Auth0のSSO Dashboard拡張機能の使用を選んだ場合には、SSOに有効化できる複数のエンタープライズアプリケーションをダッシュボードが一覧表示するように作成できます。その場合には、ログインするユーザーにそのダッシュボードが表示されます。
ユースケース
企業間（B2B）
企業間（B2B）のシナリオでは、SSOにより、エンタープライズで使用するアプリケーションのパッケージ化が簡単になります。Auth0を使用すると、Active Directory（AD）、Lightweight Directory Access Protocol（LDAP）、Ping・Security Assertion Markup Language（SAML）など、一般的なエンタープライズフェデレーションのシナリオにアプリケーションを対応させることができます。そのため、パートナーや企業顧客は、各自のエンタープライズID技術を使ってログインできます。
企業と消費者間（B2C）CIAM
企業と消費者間（B2C）またはCustomer Identity Access Management（CIAM）のシナリオでは、SSOによりアプリケーションやサービスにスムーズなアクセスを提供できます。お客様にアカウントの作成を要求するのではなく、Google・Facebook・LinkedIn・X・Microsoftなど、人気のソーシャルIDプロバイダーで認証できるようにします。