メインコンテンツへスキップ
B2E (Business to Employees) のシナリオでは、従業員ユーザーが使用するアプリケーションを扱います。これらのアプリケーションは、ユーザーが自分自身のためではなく、雇用主、大学、または所属するグループなどの組織を代表して行動する場合を主な対象としています。 組織が独自に開発したこのようなアプリケーションでは、認証を外部化するために OIDC/ プロトコルを使用することがあります。一方、購入したアプリケーションでは、多くの場合 プロトコルが使用されます。いずれの場合も、エンタープライズでは通常、エンタープライズユーザーの認証に、SAML 、ADFS、Google Workspace、Azure AD、AD や OpenLDAP などのディレクトリサービス、さらに頻度は低いもののカスタム DB など、何らかの Enterprise 接続を利用したいと考えます。 B2E 環境向けに Auth0 を使用してアプリケーションを作成または統合する企業には、このシナリオに共通する要件がいくつかあります。このガイドでは、B2E アプリケーションで最も一般的な要件を要約し、それぞれのニーズに対応する Auth0 の機能を説明します。

エンタープライズプロバイダー

ほとんどの企業では、全従業員のユーザー情報やユーザープロフィール情報を保持する企業の ID リポジトリをすでに備えています。そこには、パートナーや委託業者に関する情報も含まれている場合があります。そのため、B2E シナリオでよくある要件の 1 つは、そうしたユーザーが SAML2 プロバイダー、ADFS、Google Workspace、Azure AD、またはオンプレミスの企業ディレクトリサービスなどの Auth0 エンタープライズ接続 を通じてログインできるようにすることです。これは、アプリケーションごとに新たなユーザー名とパスワードを作成する必要がなくなり、同じログイン認証情報をすべてのエンタープライズアプリケーションで利用できるため、ユーザーにとって魅力的です。 これは、ユーザーの認証情報が各アプリケーションではなく ID 基盤にのみ渡されるため、社内のセキュリティ担当者にとっても特に魅力的です。さらに、このアーキテクチャでは、エンタープライズ IDプロバイダーが一元的な停止点を提供するため、企業はアプリケーションへのアクセスを継続的に制御できます。ユーザーが組織を離れた場合は、管理者が企業の IDプロバイダーでそのユーザーのアカウントを無効にするだけで、その IDプロバイダーを使用するどのアプリケーションにもログインできなくなります。 Auth0 を使えば、いくつかの簡単な設定手順だけで、さまざまなエンタープライズプロバイダーによるログインを簡単に有効にできます。

グループとロール

ユーザー数が多い場合は、アクセスや権限を管理するためにグループやロールを設定できます。こうした情報は、多くの場合、ディレクトリサービスに保存され、管理されます。 Auth0 は、認証時にディレクトリサービスまたはエンタープライズ IDプロバイダーから、グループやロールなどのユーザー属性を取得できます。その後、アプリケーションに返されるトークンや Auth0 の を通じて、これらの属性を利用できるようにできます。

プロフィールの変換

ディレクトリやIDプロバイダーから返される属性の形式が、アプリケーションで使用している形式と異なる場合があります。Auth0のRulesを使用すると、ユーザープロフィール属性をマッピングして変換できます。さらに、OIDC/OAuth、SAML、、LDAP の間で変換することもできます。 たとえば、SAML IDプロバイダーから SAML アサーション形式の属性を取得するとします。Rule を使用すると、それらの属性を OIDC/OAuth アプリケーション向けの 内のカスタムクレームに変換できます。 また、Dashboard から SAML 属性を Auth0 のユーザープロフィールにマッピングすることもできます。これを行うには、Connections > Enterprise > SAMLP Identity Provider に移動し、SAML 接続を選択して、Mappings タブで属性マッピングを設定します。

拡張されたユーザープロフィールを使った拡張機能

他のサービスから取得した属性やデータを使って、ユーザープロフィールを拡充したい場合があります。たとえば、住所や電話番号を受け取り、それを地理的な地域情報に変換したいことがあるでしょう。Auth0 Rules を使用すると、認証トランザクション中に実行される小さなコードスニペットを記述できます。これにより、ロジックを実行したり、ユーザー情報を取得するために他のサービスを呼び出したりして、ユーザーメタデータ を Auth0 のユーザープロフィールに追加し、必要に応じてアプリケーションに送信されるトークンにも含めることができます。

シングルサインオン

複数の社内アプリケーションがある場合は、それらの間で シングルサインオン (SSO) を設定することで、ユーザーは 1 回ログインするだけで済むようになります。 Auth0 は、業界標準の ID プロトコルを使用して認証を外部化するアプリケーションとの統合をサポートしています。
  • OIDC/OAuth
  • SAML2
  • WS-Fed
必要な設定を行うと、すべてのアプリケーションでエンタープライズ IDプロバイダーを活用できるようになります。この構成では、Auth0 はアプリケーションとエンタープライズ IDプロバイダーの間の仲介役となります。 これにより、ユーザーが 1 つのアプリケーションにサインインすると、 セッションの有効期限が切れるまで、再度ログインしなくても Auth0 と統合された他のアプリケーションにアクセスできます。セキュリティポリシーに適合するよう、Auth0 で SSO セッションの有効期間を設定してください。

シングルサインオン統合

購入済みのアプリケーションを Auth0 と統合して、シングルサインオン (SSO) を実現することもできます。Auth0 では、次のようなアプリケーション向けにあらかじめ用意された統合を提供しています。
  • Salesforce
  • Zendesk
  • Slack
  • New Relic

ブランディング

ブランディングは、あらゆるアプリケーションにとって重要です。ロゴ、色、スタイルは、アプリケーション全体で一貫している必要があります。Auth0 が表示するログイン、サインアップ、エラーページは、アプリケーションに合わせてカスタマイズできます。独自のロゴ、テキスト、色を追加することもできます。グローバル展開に向けた I18N/L10N のサポートもあります。さらに、確認やパスワードリセット用のメールもカスタマイズ可能です。 ログイン画面は、アプリケーションのブランドに合わせたドメイン名から提供されているように見える必要があります。一貫性を保つため、Auth0 が表示するログイン画面用にカスタムドメイン名を定義できます。

多要素認証

社内アプリケーションや従業員向けアプリケーションでは、機密性の高いコンテンツを扱うことが少なくありません。 多要素認証 (MFA) は、データとアプリケーションの保護に役立ちます。Auth0 では、 を実装するためのさまざまな方法を提供しています。さらに柔軟に運用するために、Rules を使用して、必要なアプリケーションやユーザーグループに対してのみ有効にすることもできます。

ログのエクスポート

ログを分析したり、長期間保存したりする必要がある場合、Auth0 では分析と保持のためにログを外部ツールにエクスポートする拡張機能を提供しています。Management API を使用してログデータを取得することもできます。

監査

企業ではログデータをさまざまな目的で活用しますが、その用途の1つが監査レポートです。Auth0 はログファイルにさまざまなデータを記録しており、監査レポートの作成に役立つ場合があります。ログには、認証されたユーザー、使用されたIDプロバイダー、さらに で重要な管理上の変更が行われた時刻に関する情報が含まれます。 各ログイベントにはイベントタイプがあります。Management API でログデータを照会するときや、ログをログ分析ツールにエクスポートするときに、イベントタイプをフィルターとして使用できます。

モニタリング

アプリケーションが依存するインフラストラクチャやサービスをモニタリングすることは重要です。Auth0 では、購読可能な Auth0 Status ページを提供しています。 Auth0 はサービス停止の最小化に最大限努めていますが、サービスに何らかの影響が発生した場合は、ステータスページに表示されます。中断後の根本原因分析に関する文書化要件に対応するため、Auth0 は内部分析を実施し、分析が完了すると、その結果を障害通知に公開します。

アタックプロテクション

現代のインターネットでは、ハッカーの存在は避けられない現実です。ハッカーは常にアプリケーションへの侵入手段を探しています。たとえば、よく使われるパスワードでログインを試みることがあります。また、別の場所で盗まれた認証情報を使い、ユーザーが他のサイトでも同じパスワードを使い回していることを期待する場合もあります。 Auth0 の アタックプロテクション は、Auth0 データベース接続でこのような状況を検出し、対応方法の選択肢を提供します。 を有効にし、このような事象が発生した場合に適切に対応できるよう、応答オプションを設定してください。

GitHub デプロイ

アプリケーションコードの多くを GitHub で管理している場合は、Auth0 の GitHub Deployment 拡張機能を使用して、そこから Actions、Rules、Hooks、またはカスタムデータベースアクセス用のコードをデプロイできます。 継続的インテグレーション/継続的デプロイ (CI/CD) のパイプライン全体を構築している場合は、より柔軟に利用できる Auth0 Deploy CLI tool を使用してください。