認証（B2C）

B2CのIAM実装で認証が行われる仕組みについて説明します。

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

​

ベストプラクティス

ユーザーの認証方法を設計する際にセキュリティとユーザーエクスペリエンスの両方を考慮することは重要です。複数のプライマリ要素を提供し、および/または認証中に複数の要素を強制することで、両方を提供できます。

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

• ユーザーがどこで資格情報を入力するのか
• ユーザーに関する資格情報の安全性をどのようにして確保するのか
• 認証システムをどのようにして維持するのか
• ユーザーにパスワード認証をどのようにして提供できるのか
• ハッカーがユーザーと偽ってログインすることをどのようにして防ぐのか
• 異なる種類のアプリケーションで、どのようにして認証を実装するのか
• 異なる言語を使用するユーザーのために、どのようにしてログインしやすくできるのか
• レガシーの認証システムから移行する際に、どのようにして良好なユーザーエクスペリエンスを提供するのか
• アプリケーションをAuth0と統合する際に、どのようなことを考慮するべきなのか
• ユーザーは既存のソーシャル（FacebookやGoogleなど）アカウントを使ってログインできるのか
• 多要素認証（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）認可」に記載の認可処理ストリームを参照してください。

​

ユニバーサルログイン

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

​

ベストプラクティス

1つ以上のアプリケーションがある場合、ベストプラクティスは、「一元化された場所」にリダイレクトし、ユーザーを認証することです。Auth0を使用する場合、これはユニバーサルログインを活用することを意味します。SSOを含む多くのセキュリティとユーザーエクスペリエンスの利点が、すぐに利用できます。

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

1. アプリケーションからのリダイレクトがいつどのようにして行われるかを決めます。
2. Auth0の構成で、適切なブランディングやHTMLのカスタマイズをセットアップします。
3. 認可サーバーから応答を受け取って処理するように、アプリケーションをセットアップします。

​

ユーザー名とパスワードの認証

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

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

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

​

ベストプラクティス

一元化されたログインページでのみ資格情報を収集することで、ユーザーの機密情報が漏洩する可能性を減らすことができます。不要に資格情報を収集する必要性を減らすこともできます。詳細は「ユニバーサルログイン」をご覧ください。

​

アプリケーション統合

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

ネイティブモバイルアプリケーション（とデスクトップアプリケーション）は、認証にシステムブラウザーを使用しなければなりません。そうしないと、セキュリティリスクが高まります。詳しくは、モバイルでのネイティブとブラウザーのログインの比較を参照してください。

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

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

​

匿名アクセス

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

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

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

  • 同じAuth0テナントを使用した別のアプリケーションにすでにアクセスしたことがあるか
  • これまでに（または最近）そのデバイスまたはブラウザーを使って認証したことがあるか

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

Auth0にリダイレクトしてログインセッションを確認することはアプリケーションにとって役立ちますが、これによって大量の要求が発生する場合は、遅延やレート制限を回避するためにスロットリングメカニズムを採用する必要があります。

Management APIへの呼び出しにはAuth0レート制限ポリシーが適用されることを考慮してください。Auth0は、通常、APIを直接呼び出す代わりに、開発環境に適したAuth0 SDKを使用することを推奨しています。

​

保護されたエンドポイントにディープリンクする

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

​

ベストプラクティス

ほとんどの新しい認証フレームワークは、Auth0などの認可サーバーにリダイレクトするためのミドルウェアをサポートしています。選択する際には、以下の点を考慮してください。

• 機密クライアント、非機密クライアント、またはその両方のサポート
• [検出エンドポイント](https://auth0.com/docs/ja-jp/get-started/applications/configure-applications-with-oidc-discovery 「OIDC Discoveryでアプリケーションを構成する」）または明示的なインラインを使った構成のサポート
• 有効期限、署名、クレーム、およびスコープを含むトークン検証のサポート
• 必要であれば、リフレッシュトークンのサポート

​

ユーザーを認証する

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

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

公開する前に、各アプリケーションで使用している付与のみ がアプリケーションの構成で有効になっていることを確認してください。

​

認可コード付与（PKCEを使用または不使用）

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

Auth0では、IDトークンのみを必要とするブラウザーベースのアプリケーションに対して暗黙の付与を使用することが可能ですが、PKCEを使った認可コード付与を推奨しています。詳細については、Auth0ブログの「OAuth2の暗黙の付与とSPA」を参照してください。

ユーザーを再認証することなく新しいアクセストークンやIDトークンを取得できるようにフレッシュトークンが必要な場合は、認可コード付与を使用する必要があります。

​

攻撃の防御

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

​

ベストプラクティス

Auth0では異常の検出を水面下で行っており、お客様の製品に優れた安全機能を提供しています。この機能を活用するには、ユーザーへのメール配信を開始する前に、メールプロバイダーのセットアップと、メールテンプレートの構成を行ってください。

​

レガシーシステムを使ったSSO

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

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

​

ベストプラクティス

旧来のシステムでSSOエクスペリエンスに対応するのは、複雑になる場合がありますが、Auth0と統合する際によりシームレスなユーザーエクスペリエンスを創り出すという点において行う価値があるでしょう。この方向に進む予定でしたら、早めに計画を立てることで達成が可能になります。まだ一元化されたサービスにSSOを導入されていない場合は、追加に伴う複雑さが利益に見合わない可能性が高いです。

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

​

ソーシャル認証

FacebookやGoogleなどが提供するBring Your Own Identity（BYOI：個人IDの持ち込み）のシナリオは、セキュリティを危険にさらすことなく、ユーザー認証エクスペリエンスを簡素化できる貴重な方法です。ユニバーサルログインを使用すると、変更に伴う影響を最小限に抑えつつソーシャル接続への対応を追加しやすくなります。

Auth0では、事前構成された開発者キーを使ってソーシャル接続を簡単にテストすることができます。ただし、制限があるため、運用に入る前に、利用するソーシャルプロバイダーの指示に従って独自のアプリケーション固有のキーをセットアップする必要があります。

ソーシャルに対応していると、ユーザーの身元や資格情報はソーシャルプロバイダーによって管理されます。特定のIDクレームも同様ですが、これはAuth0がユーザーのプロファイルを入力する際に利用されます。Auth0では、ソーシャルIDプロバイダー（ソーシャルIdP）のアクセストークンも使用できるため、アプリケーションはユーザーに代わって、サードパーティのソーシャルIdPのAPIも呼び出すことができます。

​

ベストプラクティス

ソーシャルは素晴らしい機能ですが、1つ以上のサインイン方法を提供するのであれば、顧客が実際に複数の方法でサインインする可能性を考慮する必要があります。デフォルトでは、Auth0のすべてのユーザーIDにはそれぞれユーザープロファイルがあります。したがって、1つのユーザープロファイルを複数のIDと関連付ける効果的な方法として、Auth0のユーザーアカウントをリンクする機能を考慮することが適切でしょう。

Auth0のカスタムソーシャル接続拡張機能を使用すると、カスタマイズが必要なOpenID Connect（OIDC）サードパーティ準拠のベンダーに接続できるため、ソーシャル認証の適用範囲がさらに拡大されます。たとえば、政府発行のIDプロバイダーであるSwissIDは、カスタムソーシャル接続を使ってAuth0で構成することができます。

​

多要素認証（MFA：Multi-factor authentication）

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

​

ベストプラクティス

顧客向けアプリケーションでは、ユーザーに第二要素の追加を「強制」するのではなく、選択肢として提供することが非常に一般的です。詳細は、「ユーザーにMFAを追加するオプションを提供する」をご覧ください。

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

• Auth0 Guardian：プッシュ通知の生成、そして、要求の許可と拒否を扱うアプリケーションを両方提供するサービスです。プッシュはユーザーの登録済みデバイス（一般的に携帯電話やタブレット）に通知を送信します。ユーザーはボタンを押すだけで、デバイスから即座にアカウントへのアクセスを許可または拒否することができます。
• 時間ベースのワンタイムパスワード（TOTP）：デバイスでGoogle Authenticatorなどのアプリを利用して、一度限りのパスワードを生成します。生成されるパスワードは一定期間で切り替わり、ユーザーアカウントを検証する第二要素として入力することができます。
• SMS：SMSでワンタイムコードを送信します。ユーザーが認証を完了するには、このコードを入力する必要があります。
• 音声：電話での通話を使ってワンタイムコードを提供します。ユーザーが認証を完了するには、このコードを入力する必要があります。
• Duo：多要素認証にDuoアカウントを使用できるようにします。
• メール：多要素認証にメールアカウントを使用できるようにします。

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

​

プロジェクト計画ガイド

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

B2C IAM Project Planning Guide