メインコンテンツへスキップ
(SSO) とは、ユーザーが1つのアプリケーションにログインすると、ユーザーが利用しているプラットフォーム、テクノロジー、ドメインに関係なく、他のアプリケーションにも自動的にサインインされる仕組みです。ユーザーがサインインするのは1回だけであることが、この機能名の由来です (Single Sign-on) 。 たとえば、Gmail などの Google サービスにログインすると、YouTube、AdSense、Google Analytics、その他の Google アプリにも自動的に認証されます。同様に、Gmail や他の Google アプリからログアウトすると、すべてのアプリから自動的にログアウトされます。これはシングルログアウトと呼ばれます。 SSO は、ユーザーがアプリケーションやサービスを利用する際にシームレスな体験を提供します。各アプリケーションやサービスごとに別々の認証情報を覚える必要はなく、1回ログインするだけで一連のアプリケーションすべてにアクセスできます。 ユーザーが認証を必要とするドメインにアクセスすると、認証ドメインにリダイレクトされ、ログインを求められる場合があります。ユーザーがすでに認証ドメインでログインしていれば、再度サインインすることなく、元のドメインにすぐにリダイレクトされます。

​
仕組み

sessions を使用すると、シングルサインオンとシングルログアウトを実現できます。SSO を使用するユーザーには、最大 3 種類の異なるセッションが存在する場合があります。
  • アプリケーションによって維持されるローカルセッション
  • SSO が有効な場合の セッション
  • ユーザーが 経由でログインすることを選択した場合の セッション (Google、Facebook、またはエンタープライズ IDプロバイダーなど)
SSO では、中央のドメインが認証を実行し、その後ほかのドメインとセッションを共有します。セッションの共有方法は SSO プロトコルによって異なる場合がありますが、基本的な考え方は同じです。 たとえば、認証ドメインは、認証が必要なほかのドメインでユーザーを識別するために必要なすべての情報を含む、署名付きの JSON Web Token (JWT) (JSON Web Encryption (JWE) を使用して暗号化) を生成する場合があります。このトークンはクライアントに渡されますが、署名されているため、クライアントがこれを変更することはできません。このトークンはリダイレクトによって元のドメインに渡され、認証ドメインやほかのドメインでユーザーの識別に使用できます。

​
Universal Login での SSO

Auth0 でシングルサインオン (SSO) を実装する最も簡単で安全な方法は、認証に Universal Login を使用することです。実際、現時点では、アプリケーションで を使用している場合にのみ、ネイティブプラットフォーム (iOS や Android など) で SSO を利用できます。Swift および Android のクイックスタートには、Universal Login の使用例がいくつか掲載されています。 アプリケーションで Universal Login を使用できない場合は、埋め込み認証の詳細について以下を参照してください。
シングルサインオンで Passwordless を使用している場合、接続パラメーター sms と email では既存の Auth0 セッションは利用されないため、ユーザーはログインを求められます。

​
初回ログイン時の SSO

Auth0 で SSO を使用する場合、Central Service は Auth0 の です。 ユーザーが初めてログインする際の SSO フローの例を見てみましょう。
  1. アプリケーションはユーザーをログインページにリダイレクトします。
  2. Auth0 は、既存の SSO cookie があるかどうかを確認します。
  3. ユーザーがログインページを訪れるのは今回が初めてで、SSO cookie も存在しないため、設定したいずれかの接続を使用してログインするよう求められます。
    timesheets アプリケーションのログイン画面の例
  4. ユーザーがログインすると、Auth0 は SSO cookie を設定し、ユーザーをアプリケーションにリダイレクトするとともに、ユーザーの識別情報を含む IDトークン を返します。

​
2回目以降のログインでの SSO

ユーザーが再度 Web サイトを訪問したときの SSO フローの例を見てみましょう。
  1. アプリケーションがユーザーをログインページにリダイレクトします。
  2. Auth0 は既存の SSO Cookie があるかどうかを確認します。
  3. Auth0 は SSO Cookie を見つけ、必要に応じて更新します。ログイン画面は表示されません。
  4. Auth0 はユーザーをアプリケーションにリダイレクトし、ユーザーの識別情報を含む IDトークンを返します。

​
ユーザーの SSO 状態を確認する

アプリケーションからユーザーの SSO 状態を確認するには、auth0.js SDK の checkSession メソッドを呼び出します。これにより、iframe 内でユーザーのサイレント認証が試行されます。認証が成功したかどうかで、ユーザーにアクティブな SSO Cookie があるかどうかを判断できます。

​
プロトコル

​
SAML と WS-Federation

Security Assertion Markup Language (SAML) と Web Services Federation () は、どちらも SSO の実装で広く使用されているプロトコルです。SAML と WS-Fed はいずれも、認可および認証に関するデータを XML 形式でやり取りします。このやり取りの主な要素は、ユーザー、IDプロバイダー、サービスプロバイダーです。 SAML または WS-Fed では、次のように動作します。
  1. ユーザーがサービスプロバイダーにリソースを要求します。
  2. サービスプロバイダーは、ユーザーにそのリソースへのアクセスを許可すべきかどうかを IDプロバイダーに確認します。
  3. IDプロバイダーはユーザーのアイデンティティを検証し、有効であれば、そのユーザーにアクセスを許可すべきであることをサービスプロバイダーに表明します。

​
OpenID Connect

Connect (OIDC) は、一般的にコンシューマー向けSSOの実装で使用される認証プロトコルです。OIDCプロトコルでは、と中央のIDプロバイダーを通じて認証を処理します。 OIDCでは、次の流れで処理されます。
  1. ユーザーがアプリケーションへのアクセスを要求します。
  2. アプリケーションは、認証のためにユーザーをIDプロバイダーにリダイレクトします。
  3. IDプロバイダーがユーザーを認証し、成功すると、アプリケーションへのデータアクセスを許可するようユーザーに求めます。
  4. アクセスが許可されると、IDプロバイダーはIDトークンを生成します。このIDトークンには、アプリケーションが利用できるユーザーの識別情報が含まれます。
  5. IDプロバイダーはユーザーをアプリケーションに戻します。

​
AD/LDAP

Lightweight Directory Access Protocol (LDAP) は、複数のアプリケーションで共有可能な認証情報ディレクトリにアクセスするためのアプリケーションプロトコルで、一般にイントラネットで使用されます。Active Directory (AD) と組み合わせることで、LDAPはユーザーアイデンティティを一元的に管理する場所を提供し、アプリケーションは LDAP/AD サーバーに認証リクエストを送信します。LDAPプロトコルでは、LDAP Data Interchange Format (LDIF) で情報をやり取りします。

​
サービスプロバイダー主導の SSO

サービスプロバイダー主導の SSO では、Auth0 が SSO のサービスプロバイダー (SP) です。 ユーザーがアプリケーションにログインすると、次のようになります。
  1. アプリケーションは、1 つ以上の外部 IDプロバイダーをユーザーに提示します。
  2. ユーザーは認証に使用する IDプロバイダーを選択してログインします。
  3. 認証に成功すると、ユーザーはアプリケーションに戻ります。
Auth0 の SP 主導 SSO は、接続によって処理されます。

​
IDプロバイダー主導のSSO

IDプロバイダー主導のSSO では、サードパーティのIDプロバイダー (IdP) がSSOプロバイダーとなります。 ユーザーがアプリケーションにログインする際:
  1. アプリケーションはユーザーをIDプロバイダーにリダイレクトします。
  2. サードパーティのIDプロバイダーが認証と認可を行います。
  3. 認証に成功すると、ユーザーはアプリケーションに戻されます。
IdP 主導の SSO 実装を計画する際は、Auth0 の SSO Dashboard Extension を使用することもできます。これにより、複数のエンタープライズアプリケーションを一覧表示し、SSO を有効にできるダッシュボードを作成できます。作成したダッシュボードをユーザーに提示することで、そこからログインできるようになります。

​
ユースケース

​
企業間 (B2B)

B2B のシナリオでは、SSO によってアプリケーションをエンタープライズ向けに提供しやすくなります。Auth0 を使用すると、アプリケーションで Active Directory (AD) 、Lightweight Directory Access Protocol (LDAP) 、Ping、SAML など、一般的なエンタープライズ フェデレーションのシナリオをサポートできます。これにより、パートナーやエンタープライズ顧客は、使い慣れたエンタープライズ ID 技術を使用してログインできます。

​
B2C 向け CIAM

Business to Consumer (B2C) または Customer Identity Access Management (CIAM) のシナリオでは、SSO によってアプリケーションやサービスにシームレスにアクセスできるようになります。顧客に新たなアカウントの作成を求める代わりに、Google、Facebook、LinkedIn、X、Microsoft などの主要なソーシャル IDプロバイダーを通じて認証させることができます。