認証（B2B）

ユーザーにサービスを提供するためには、ユーザーが誰なのかを識別する必要があります。この処理はユーザー認証と呼ばれます。ソーシャルメディアのアカウント、ユーザー名とパスワード、パスワードレスなど、ユーザー認証にはいくつかの方法があります。また、多要素認証（MFA）を有効にして、ユーザーを認証する際に第一要素のみに依存しないことが推奨されています。

機能性とワークフローを検討する際には、以下のように、考慮するべき事柄がいくつかあります。

• ユーザーがどこで資格情報を入力するのか

• ユーザーに関する資格情報の安全性をどのようにして確保するのか

• 認証システムをどのようにして維持するのか

• ユーザーにパスワード認証をどのようにして提供できるのか

• ハッカーがユーザーと偽ってログインすることをどのようにして防ぐのか

• 異なる種類のアプリケーションで、どのようにして認証を実装するのか

• 異なる言語を使用するユーザーのために、どのようにしてログインしやすくできるのか

• レガシーの認証システムから移行する際に、どのようにして良好なユーザーエクスペリエンスを提供するのか

• アプリケーションをAuth0と統合する際に、どのようなことを考慮するべきなのか

• 多要素認証（MFA）を提供する必要があるのか

• ユーザーが事前にログインする方法をサービスが提供できない場合にはどうするのか

• ユーザーについて、同じアクセストークンを1つのAPIから別のAPIへ渡すことができるのか

• 組織ごとにユーザーの分離が必要な場合にはどうするのか

• ユーザーが所属する組織の識別をどのようにして処理するのか

• 組織にエンタープライズ接続を提供することに、どのような利点があるのか

Auth0のユニバーサルログインは、サインインにユーザーIDとパスワードの資格情報を提供するのか、いわゆるBring Your Own Identity（BYOI：個人IDの持ち込み）のシナリオでソーシャルログインを許可するのかといった方法にかかわらず、安全でセキュリティー保護されたユーザーエクスペリエンスを提供します。また、製品固有のブランディング要件がある場合でも、ユニバーサルログインでログインエクスペリエンスを中央集中化すると、ブランドの認知度を高める効果もあります。ユニバーサルログインで通常使用されるAuth0のUIウィジェットには、そのままで便利に使える対応として、異なる言語が要求されるユーザー向けの国際化、ユーザーアカウントにアクセスしようとするハッカーからの保護障壁となるMFAや攻撃防御も備わっています。

ユーザーIDとパスワードの資格情報を使ってサインインできるようにすることは、サードパーティーIDプロバイダーのステータスに依存することなく、ユーザーによるシステムへのアクセスを許可することになります。また、会社の方針に合致した資格情報を要求する手段にもなります。これが実現できるように、Auth0には、ユーザーIDとパスワードのログインに対応する複数のオプションがあります。また、提供しているガイダンスには、それらのオプションを活用する方法が説明されています。追加の主要な認証要素として、何らかのステージでソーシャル対応を追加すると、柔軟性が高まり、各種のソーシャルログインプロバイダーがすでに保管している情報を活用して、ユーザーに質問することなく、ユーザーについての理解を深めることができます。

既存のレガシーIDストアがある場合には、「ユーザーの移行」も併せて参照してください。そのセクションには、安全性とセキュリティー保護の面で、Auth0が管理するIDストレージへ移行することの利点が説明されています。

顧客向けのアプリケーションでは、OpenID Connect（OIDC）が最も広く使われている業界標準プロトコルであり、Auth0でも第一級オブジェクトの対応を提供しています。Auth0は、さまざまなアプリケーションを統合できるように、さまざまな方法に対応しています。アプリケーションの統合に関するセクションで必要な情報を確認し、よく理解したうえで選ぶことをお勧めします。

1つ以上のcronジョブ、レポートの生成機能、CI/CD（継続的インテグレーション/継続的デリバリー）システムなど、認証済みのユーザーが存在しないあらゆる状況で1つのAPIから別のAPIを呼び出す際には、ユーザーではなく、アプリケーションを認証する方法が必要になります。これは、1つの呼び出しでアプリケーションが認証（クライアントIDとシークレットを使用）されて認可されるという、1ステップのプロセスです。詳細については、「マシンツーマシン（M2M）認可」に記載の認可処理ストリームを参照してください。

会社で組織ごとにユーザーを分離させる必要があったり、あるいは1人のユーザーが複数の組織にアクセスできたりすることがあります。自社がどちらのシナリオに該当するのかが分かると、ユーザーが存在する接続、実行の必要性、必要なタイミング、達成方法をどのようにして判断するのか決めやすくなります。該当するかどうかの判断には、「ホームレルムディスカバリー（HRD）」を参照してください。

システムにアプリケーションが複数存在するか、複数作成する予定の場合には、サインインエクスペリエンスを中央に集中させることが得策です。複数のアプリケーション間でシングルサインオン（SSO）エクスペリエンスをシームレスするには、認証に一本化したユーザーのリダイレクト先を設けることが重要です。そうすることで、今後ソーシャル認証を追加したり、システムにサードパーティーのアプリケーションを追加したり、ユーザーに対するオプション（または要件）として多要素認証を追加したりする場合でも、ユーザーエクスペリエンスの一貫性が保たれます。また、ユーザーエクスペリエンスを向上させるために、開発をほとんど行うことなく新しい機能を活用できようになります。

Auth0のユニバーサルログインでは、ユーザーの認証が以下の手軽な3ステップで完成し、プロセスが短く簡単になります（Quickstartsに実践的な説明があります。また、SDKを使うと複雑な手間を省くことができます）。

1. アプリケーションからのリダイレクトがいつどのようにして行われるかを決めます。

2. Auth0の構成で、適切なブランディングやHTMLのカスタマイズをセットアップします。

3. 認可サーバーから応答を受け取って処理するように、アプリケーションをセットアップします。

ホームレルムディスカバリー（HRD）は、認証に先だって、ユーザーがどのIDプロバイダー（またはAuth0の接続）に属しているのかを識別するプロセスです。HRDの実行には以下の2通りがあります。

• アプリケーションで決定する方法を提供する

• ユニバーサルログインページでHRDを処理する

システムにいずれかまたは両方の手段が必要かもしれないため、アプリケーションに最適なものを実装できるように、HRDのどちらの方法も理解することが大切です。

ユーザーが属するレルムを判断する方法として最も一般的なのは、それぞれの組織について、アプリケーションにブランドがある場合です。ブランディングの一環として、組織には通常独自のアプリケーションインスタンスがあり、異なるURLを使ってアクセスされます。このコピーやインスタンスは物理的に分離（別のサーバーセット上で実行）、または仮想的に分離（共有のサーバー上で実行）され、通常はカスタムのホスト名（companyA.application1.yourcompany.com）またはパス（application1.yourcompany.com/companyA）で示されます。

アプリケーションにこれが該当する場合、HRDの処理は単にorg_idをアプリケーション特定の構成と共に保管し、ユーザーをユニバーサルログインにリダイレクトする際にそれを組織のパラメーターとして送信するだけになります。そうすることで、ユーザーが特定の組織とその構成にある接続のみに制約されます。

ユーザーが1つのIDを使って複数の組織で共有されている場合には、ユニバーサルログインページをHRDに対応させる必要があります。ユニバーサルログインはユーザーを識別してから、そのユーザーに適したレルムを表示するため、ユーザーエクスペリエンスの向上に繋がります。

組織や接続のパラメーターは、ユーザーを/authorizeエンドポイントにリダイレクトする際にクエリパラメーターとして追加することにより送信できます。詳細については、Authentication APIのドキュメントを参照してください。一般的に、アプリケーションの作成に使った言語が何であっても、これにはSDKを活用することができます。

HRDには主に以下の3つの方法があります。

• ユーザーのメールのサブドメインを使ってレルムを特定する

• 識別子とレルムがマッピングされた何らかのマップでユーザーの識別子を探してレルムを特定する

• ユーザーが自分のレルム（または組織）を選んで入れるようにする

最初の2つの方法では、「Identifier Firstログイン」の実行を検討することができます。つまり、先に識別子を入力できるような機能性のみを提供します。その後、ユーザーの識別子を収集し、識別子に応じてユーザーを自動的にリダイレクトするか、リダイレクトが不要な場合にはユーザーがパスワードを入力できるようにします。Auth0には、これをすべて行うのに、変更することなくそのまま使える実装があり、ユニバーサルログインを使用します。

ユニバーサルログインページにHRDを実装する最も簡単な方法は、ユーザーの識別子にあるメールのサブドメインを利用して、それをページのIDプロバイダーにマッピングすることです。もちろん、これはメールのサブドメインと組織、または少なくともIDプロバイダーが1対1でマッピングされる状況でのみ有効になります。

エンタープライズ接続にドメインのマップがある場合、Auth0のLockウィジェットやユニバーサルログインはこれを処理できますが、独自に構築したいのであれば手動で処理することもできます。ただし、その場合には、メールのサブドメインと接続のマッピングを構築する必要があります。

また、ユニバーサルログインエクスペリエンスを使う際には、Organizations機能が以下の2つの点で役立ちます。

1. ログイン要求を始める際にorg_idが/authorizeエンドポイントに渡されなかった場合、Auth0はユーザーが属する組織の入力をユーザーに求めます。

2. Organizationに複数のIdPが関連付けられている場合、Auth0は組織を選択するボタンか、ユーザー名とパスワードを入力するフォームをユーザーに提供します。

2つ目の、より複雑な方法としては、識別子とIdPのマッピングを保管して、パブリックエンドポイントにその情報へのアクセスを提供するというものがあります。そして、ユニバーサルログインページでは、接続を見つけてから、その接続を使って/authorizeエンドポイントにリダイレクトで戻します。この方法の主な欠点は遅延があること、そして、より重大な欠点は、識別子の発見に伴うセキュリティ保護です。メールアドレスを使っている場合は、この方法で、特定のメールアドレスと所属するユーザーとの関連性が発見しやすくなります。

上記の他に、プロダクトを使用している組織のリストが公開されたり、ユーザーが自分の組織名を明示的に入力できたりしても構わないのであれば、ユーザーがリストから選択できるようにするというオプションもあります。これは通常、ユーザーをユニバーサルログインにリダイレクトする前に行われます。ユーザーが所属する組織を選択すると、その組織の接続でAuth0にリダイレクトすることができます。データベース接続の場合には、Auth0にユーザーのユーザー名とパスワードを要求させることができます。

ほとんどすべてのB2Cアプリケーションは、顧客が新しい資格情報セットを作成できる機能性を提供しています。すべてのユーザーに慣れ親しまれている、一般的な認証形式です。

Auth0には、さまざまなユーザー名とパスワードの認証があります。アプリケーションが生まれたばかりで、既存のユーザーベースがない場合には、Auth0提供のそのままで使える簡素なデータベース接続が、ユーザーを認証し始めるのに必要なすべてを備えており便利です。しかし、レガシーのユーザーストア（独自のユーザーデータベースや既存のLDAPシステムなど）がある場合、「ユーザーの移行」のガイダンスにもあるように、ユーザーを移行する2つの方法があります。

データベース接続のためにユーザーをどのようにプロビジョニングしたとしても、ユーザー認証は非常に似通っています。ユーザー名とパスワードの入力フォームをユーザーに提供する必要があります。ユニバーサルログインのガイダンスでも説明したように、ユーザー名とパスワードを使ったユーザー認証で最もシンプルかつ安全な方法は、中央管理のログインページにリダイレクトして、そこでユーザー名とパスワードを収集することです。そうすると、Auth0がすでに認証済みかを判断し、必要でない場合にはログインフォームを完全にスキップできるようになります。

ユーザーをどのようにして認証したいかが決まったら、次のステップとして、認証をどのように始めるのかを決定します。一般的に、アプリケーションにはそれぞれ独自の始点があります。

上でも述べたように、顧客向けのアプリケーションでは、ほとんどの顧客がOpenID Connect（OIDC）を業界標準プロトコルとして使用しています。どのOIDCフローを使うのか見当をつけるためには、まず、付与のマッピングに関するガイダンスを確認してください。

アプリケーションのどこか一部を匿名のユーザーにも使えるようにしたい場合には、即座にリダイレクトするのか、必要なときにだけユーザーにリダイレクトを促すのか（またはその2つを何らかの形で組み合わせたものにするのか）を決める必要があります（詳細は「ログイン後にユーザーをリダイレクトする」を参照）。ユーザーがサイトの保護されたバージョン（または領域）にディープリンクできる場合には、結果的にAuth0に自動リダイレクトされる、アプリケーションへのリンクを行うかどうか決める必要があります。

アプリケーションを初めて使うユーザーのユーザーエクスペリエンスを考慮することは重要です。アプリケーションが匿名ユーザーに対応している場合（Eコマースのアプリケーションでは一般的）には、以下のように、考慮するべきシナリオがいくつかあります。

• すでにログインしたことがあり、アプリケーションに戻って来ている

• アプリケーションに初めてアクセスしている

  • 同じAuth0テナントを使用した別のアプリケーションにすでにアクセスしたことがあるか

  • これまでに（または最近）そのデバイスまたはブラウザーを使って認証したことがあるか

匿名ユーザーがアプリケーションにアクセスする際には、ユーザーがすでに同じ系列の別のアプリケーションにログイン済みかをアプリケーションが発見できる、または、アプリケーションが状態のないSPAだとしても、ユーザーを覚えていることができる方が望ましいことがよくあります。たとえば、ユーザーがすでにログイン済みだと分かれば、アプリケーションのUIヘッダーにログインボタンを表示しないで、代わりにユーザーのアカウントやプロファイルのメニューを表示することができます。これを行うには、「サイレント認証」を活用することになります。サイレント認証を使用すると、ユーザーにログインを促すことなく、ユーザーがログイン済みかを確認できます。ログインしていない場合、アプリケーションは必要に応じてログインボタンを表示することができます。ユーザーがすでにログイン済みの場合には、トークンを受け取るため、ログインボタンを再度ユーザーに表示する必要はありません。

認証されたユーザーにのみアクセス可能なアプリケーションについて、人はさまざまな理由から、特定のページに直接リンクしたいと考えます。これがアプリケーションで可能な場合、認証されていないユーザーは必ず自動的にAuth0にリダイレクトする必要があります。認証が終わると、認可サーバーはユーザーをアプリケーションに戻します。その際には、元々目的としていた場所にユーザーをリダイレクトすることができます。

認証とは、ユーザーの身元を特定するプロセスのことです。認証の結果は、OIDCではIDトークンになります。このトークンにはユーザーについての情報が含まれているため、認可サーバーに定義された1つ以上の要素（最も一般的なのはユーザーIDとパスワード）を使ってユーザーが認証するときにのみ取得可能でなければなりません。IDトークンの取得以外に、以下も併せて考慮する必要があるかもしれません。

• 共有のAPIを呼び出すのにアクセストークンも必要なのか

• アプリケーションがシングルページアプリケーション（SPA）で、IDトークンのみが必要なのか。詳細については、「PKCEを使った認可コード付与」を参照してください。

• アプリケーションがネイティブアプリケーション（モバイルまたはデスクトップ）か、そして/またはリフレッシュトークンが必要なのか。詳細については、「PKCEを使った認可コード付与」を参照してください。

SDKが認可コード付与のみに対応しているか、アクセストークンまたはリフレッシュトークンが必要な場合には、認可コード付与（PKCEを使用または不使用）を使ってIDトークンを取得することもできます。認可コード付与には、トークンのコードをやり取りする追加のAPI呼び出しが含まれているため、IDトークンだけが必要な場合には不要な遅延が発生するかもしれません。多くの場合、アクセストークンとリフレッシュトークンの安全な取得に認可コード付与のワークフローを活用しながら、IDトークンへのアクセスを最適化するためにハイブリッドフローが実装されます。

認証システムが重要な理由は、悪意のある行為者が権限のないアプリケーションやユーザーデータにアクセスすることを防ぐためです。我々は、悪意のある行為者とシステムへのアクセスの間に、できる限り多くの障壁を配備したいと考えます。最も簡単な方法は、Auth0で攻撃防御を確実に正しく構成することです。そのためにも、このトピックに関するガイダンスを注意して読み、正しく動作していることを確認してください。

大規模な再編成では、すべてのアプリケーションを一度に更新することが常に可能（または現実的）だとは限りません。実際に、Auth0との統合に関して推奨されるベストプラクティスは、繰り返し（反復的に）更新する方法で計画することです。アプリケーションがすでにシングルサインオン（SSO）を利用し、レガシーシステムがOIDCやSAMLなどのプロトコルに対応していて、Auth0と統合しながらもSSOを引き続き提供したい場合には、以下の2つのオプションがあります。

• レガシーのSSOシステムに既存のIDプロバイダーを更新して、ログイン（SAMLを使うなど）はAuth0にリダイレクトする

• ログインでは、Auth0がレガシーのSSOシステムにリダイレクトする。これには、レガシーシステムをAuth0でIdPとして構成（SAMLまたはOIDCを使用）する必要があります。

これは、現在使用しているレガシーアーキテクチャに合わせて追加で調査が要求される複雑な内容となるため、レガシーシステムで現在SSOに対応している場合にのみ検討することをお勧めします。注意：現在、アプリケーションから中央管理システムにリダイレクトしてユーザーを認証し、中央管理システムとのセッションがないときにのみ、そのシステムが資格情報を求める場合には、レガシーのSSOが実装されています。

Bring Your Own Identity（BYOI：個人IDの持ち込み）のシナリオは、ほとんどすべてのB2Bアプリケーションに必須となりつつあります。ほとんどの大企業は、社員が別の資格情報セットを保管しなくてもいいように、独自のIdPをアプリケーションに統合することを期待しています。これは、セキュリティを危険にさらすことなく、ユーザー認証エクスペリエンスを簡素化できる貴重な方法です。ユニバーサルログインを使用すると、変更に伴う影響を最小限に抑えつつエンタープライズ接続への対応を追加しやすくなります。

エンタープライズ接続に対応していると、ユーザーの身元や資格情報は顧客の組織のIDプロバイダーによって管理されます。特定のIDクレームも同様ですが、これはAuth0がユーザーのプロファイルを入力する際に利用されます。

ユーザー資格情報の不正利用が史上最高を記録している現在、ハッカーによる身元情報の窃盗は頻発しており、システムを保護することは未だかつて無く困難になっています。最も効果的な方法は、アカウントを保護するために、ユーザーが第二要素を構成できるようにすることです。この方法は一般的に多要素認証（MFA）と呼ばれています。別のアプリケーションから漏洩してしまったユーザー名とパスワードが使われた場合でも、確実に権限のあるユーザー本人のみがアカウントにアクセスできるようになります。

Auth0は、MFAを有効化してユーザーアカウントのアクセスを保護するために、複数のオプションをサポートしてます。また、アクセスを制限する柔軟な第二要素が確実に提供できるように、以下のようないくつかの実践があります。

• Auth0 Guardian：プッシュ通知の生成、そして、要求の許可と拒否を扱うアプリケーションを両方提供するサービスです。プッシュはユーザーの登録済みデバイス（一般的に携帯電話やタブレット）に通知を送信します。ユーザーはボタンを押すだけで、デバイスから即座にアカウントへのアクセスを許可または拒否することができます。

• 時間ベースのワンタイムパスワード（TOTP）：デバイスでGoogle Authenticatorなどのアプリを利用して、一度限りのパスワードを生成します。生成されるパスワードは一定期間で切り替わり、ユーザーアカウントを検証する第二要素として入力することができます。

• SMS：SMSでワンタイムコードを送信します。ユーザーが認証を完了するには、このコードを入力する必要があります。

• 音声：電話での通話を使ってワンタイムコードを提供します。ユーザーが認証を完了するには、このコードを入力する必要があります。

• Duo：多要素認証にDuoアカウントを使用できるようにします。

• メール：多要素認証にメールアカウントを使用できるようにします。

GuardianやGoogle Authenticatorなどの技術を使ったMFAのワークフローは通常、携帯電話やタブレット上で実行される別のアプリケーションで提供されます。顧客に別のアプリケーションのダウンロードを求めたくない場合には、Auth0が提供しているSDKを使って、既存のモバイルデバイスアプリケーション内に第二要素のワークフローを構築することができます。

当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。

B2Bプラットフォームの多くが顧客のOrganizationを何らかの形で分離・ブランディングし、これがIDおよびアクセス管理（IAM）システムをさらに複雑にしています。この問題でお困りであれば、当社がそのような環境に合ったガイダンスとベストプラクティスをご紹介していますので、時間を割いてお読みになることをお勧めします。

複数Organizationアーキテクチャ