利点
Auth0 の SSO を使用する理由- 統合アクセス: ユーザーは一度認証すれば、資格情報を再入力することなく、関連するすべての独立したアプリケーションにアクセスできます。
- 一元化されたセッション: Auth0 は中央のドメインとブラウザー Cookie を使用して、複数のアプリケーション間で認証状態を共有します。
- Universal Login: Auth0 の Universal Login を利用すれば、あらゆるプラットフォームで SSO を安全に実装できます。
仕組み
シングルサインオンとシングルログアウトは、セッションを利用することで実現できます。SSO では、ユーザーに対して最大 3 種類の異なるセッションが存在する場合があります。- アプリケーションで維持されるローカルセッション
- SSO が有効な場合のセッション
- ユーザーが (Google、Facebook、またはエンタープライズ IDプロバイダーなど) 経由でログインすることを選択した場合の セッション
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 フローの例を見てみましょう。- アプリケーションがユーザーをログインページにリダイレクトします。
- Auth0 は既存の SSO Cookie があるかどうかを確認します。
-
ユーザーがログインページにアクセスするのは今回が初めてで、SSO Cookie も存在しないため、設定済みのいずれかの接続を使用してログインするよう求められます。
- ユーザーがログインすると、Auth0 は SSO Cookie を設定し、ユーザーをアプリケーションにリダイレクトしたうえで、ユーザーのアイデンティティ情報を含む ID トークンを返します。
以降のログイン時の SSO
ユーザーが再度 Web サイトを訪問した際の SSO フローの例を見てみましょう。- アプリケーションがユーザーをログインページにリダイレクトします。
- Auth0 は既存の SSO Cookie があるかどうかを確認します。
- Auth0 は SSO Cookie を検出し、必要に応じて更新します。ログイン画面は表示されません。
- 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 では、次のような流れになります。- ユーザーがサービスプロバイダーにリソースへのアクセスを要求します。
- サービスプロバイダーは、ユーザーにそのリソースへのアクセスを許可すべきかどうかを、IDプロバイダーに確認します。
- IDプロバイダーはユーザーを認証し、有効であれば、そのユーザーにアクセスを許可すべきであることをサービスプロバイダーに通知します。
OpenID Connect
Connect (OIDC) は、一般消費者向けの SSO 実装で広く使われている認証プロトコルです。OIDC プロトコルは、 と一元的なIDプロバイダーを通じて認証を処理します。 OIDC では、- ユーザーがアプリケーションへのアクセスを要求します。
- アプリケーションは、認証のためにユーザーをIDプロバイダーへリダイレクトします。
- IDプロバイダーがユーザーを認証し、成功すると、アプリケーションによるデータへのアクセスを許可するようユーザーに求めます。
- アクセスが許可されると、IDプロバイダーは ID トークンを生成します。これには、アプリケーションが利用するユーザーのアイデンティティ情報が含まれます。
- 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 つ以上の外部IDプロバイダーをユーザーに提示します。
- ユーザーは認証に使用するIDプロバイダーを選択してログインします。
- 認証に成功すると、ユーザーはアプリケーションに戻ります。
アイデンティティプロバイダー起点のSSO
Identity-Provider-initiated SSO では、サードパーティのIDプロバイダー (IdP) が SSO プロバイダーとなります。 ユーザーがアプリケーションにログインすると、次のように処理されます。- アプリケーションがユーザーをIDプロバイダーにリダイレクトします。
- サードパーティのIDプロバイダーが認証および認可を行います。
- 認証が成功すると、ユーザーはアプリケーションに戻ります。
サービスプロバイダー主導のSSO とアイデンティティプロバイダー起点のSSO
サービスプロバイダー主導のSSO とアイデンティティプロバイダー起点のSSO のどちらを選ぶかは、主にユーザージャーニーの開始地点と、求められるセキュリティレベルによって決まります。 次のような認証が必要な場合は、サービスプロバイダー主導のSSO を推奨します。- 直接アクセス: ユーザーが通常、アプリケーションのログインページをブックマークしたり、ページに直接アクセスしたりする場合に使用します。
- セキュリティの強化: 特定の「Request ID」を使用してログインリクエストとレスポンスを関連付けるため、クロスサイトリクエストフォージェリ (CSRF) やリプレイ攻撃を防止でき、より安全です。
- ディープリンク: ログイン後にユーザーをアプリ内の特定のページにリダイレクトする必要がある場合に使用します。
- 企業ポータル: ユーザーが一日の始まりに、Okta、Microsoft 365、企業イントラネットなどの一元化されたダッシュボードを開き、アイコンを選択してアプリを起動する場合に使用します。
- ユーザーエクスペリエンスの簡素化: エンドユーザーが最初にアプリケーションのログインページにアクセスする必要がなくなり、すでに認証された状態でアプリケーションにアクセスできます。
- レガシーシステム: 最新のリダイレクト機能を備えていない古い SAML ベースのエンタープライズシステムと連携する際によく使用されます。