メインコンテンツへスキップ
ユーザーにサービスを提供するには、そのユーザーが誰であるかを識別できなければなりません。このプロセスはユーザー認証と呼ばれます。ユーザーを認証する方法には、ソーシャルメディアアカウント、username とパスワード、など、さまざまなものがあります。また、 (MFA) を有効にして、ユーザー認証を第1要素のみに頼らないようにすることがよく推奨されます。

​
ベストプラクティス

ユーザーをどのように認証するかを設計する際は、セキュリティとユーザーエクスペリエンスの両方を考慮することが重要です。複数の主要な認証要素を提供したり、認証時に複数の要素を必須にしたりすることで、その両方を実現できます。
機能とワークフローを検討する際には、考慮すべき点が数多くあります。
  • ユーザーはどこで認証情報を入力しますか？
  • ユーザーの認証情報をどのように安全に保ちますか？
  • 認証システムをどのように維持しますか？
  • ユーザーにパスワード認証をどのように提供しますか？
  • ハッカーがユーザーになりすましてログインしようとするのをどのように防ぎますか？
  • 異なる種類のアプリケーションで認証をどのように実装しますか？
  • 異なる言語背景を持つユーザーがログインしやすいようにするにはどうしますか？
  • 既存のレガシー認証システムから移行する際に、どのように優れたユーザーエクスペリエンスを提供しますか？
  • アプリケーションを Auth0 と統合する際には何を考慮すべきですか？
  • ユーザーは既存のソーシャルアカウント (例: Facebook や Google) を使ってログインできますか？
  • 多要素認証を提供する必要がありますか？
  • ユーザーが事前にログインする手段を持たないサービスがある場合、どうしますか？
  • 同じユーザーのを、ある API から別の API に渡せますか？
Auth0 のUniversal Loginは、ユーザー ID/パスワード認証によるサインインを提供する場合でも、Social Login による、いわゆる Bring Your Own Identity のシナリオを許可する場合でも、ユーザーに安全でセキュアな体験を提供します。製品固有のブランディング要件がある場合でも、でログイン体験を一元化することには、ブランド認知の面でも利点があります。Universal Login で通常使用される Auth0 の UI ウィジェットは、異なる言語要件を持つユーザー向けの国際化を標準でサポートしています。また、MFA や 攻撃対策 などの Auth0 機能も標準でサポートしているため、ユーザーのアカウントにアクセスしようとするハッカーを防ぐための防御策を講じることができます。 ユーザー ID/パスワード認証情報によるサインインを許可すると、ユーザーがシステムにアクセスする際にサードパーティのの稼働状況に依存しなくて済みます。また、使用される認証情報を自社のポリシーに準拠させることもできます。Auth0 は、ユーザー ID/パスワードログインをサポートする複数のオプションを提供することでこれを支援しており、提供されるガイダンスは、これらのオプションをどのように活用できるかを理解するのに役立ちます。追加の主要な認証要素として、どこかの段階でソーシャル認証のサポートを追加すると、柔軟性が高まります。また、さまざまなソーシャルログインプロバイダーにすでに保存されている情報を活用することで、ユーザーに追加で確認しなくても、ユーザーをより深く理解する助けにもなります。 既存のレガシーIDストアがある場合は、User Migrationも参照してください。このセクションでは、安全性とセキュリティの観点から、Auth0 の管理対象IDストレージに移行する利点について説明します。 顧客向けアプリケーションでは、 Connect (OIDC) が最も広く使用されている業界標準プロトコルであり、Auth0 は OIDC をネイティブにサポートしています。Auth0 では、さまざまなアプリケーションを統合するための複数のアプローチをサポートしているため、適切に選択するために必要な情報については、application integrationのセクションを参照してください。 ある API から別の API を呼び出す場合や、認証済みユーザーのコンテキストが存在しない状況、たとえば 1 つ以上の cron ジョブ、レポートジェネレーター、継続的インテグレーション／デリバリーシステムなどでは、ユーザーではなくアプリケーションを認可する方法が必要になります。これは 1 ステップのプロセスで、アプリケーションを認証し ( とシークレットを使用) 、その後 1 回の呼び出しで認可します。詳しくは、認可ワークストリームの machine-to-machine (m2m) authorization を参照してください。

​
Universal Login

システム内に複数のアプリケーションがある、または今後複数になる予定はありますか。もしあるなら、一元化されたサインイン体験が必要になります。複数のアプリケーション間でシームレスな (SSO) 体験を実現するには、認証のためにユーザーをリダイレクトする一元的な場所を用意することが重要です。これにより、将来的にソーシャル認証を追加したり、システムにサードパーティ製アプリケーションを追加したり、ユーザー向けに多要素認証をオプションまたは必須として追加したりする場合でも、一貫した体験を提供できます。さらに、ユーザー体験を向上させる新機能のメリットも、追加の開発作業をほとんど、あるいはまったく行わずに活用できます。

​
ベストプラクティス

複数のアプリケーションがある場合のベストプラクティスは、ユーザーを認証するために一元化された場所へリダイレクトすることです。Auth0 では、これは Universal Login を活用することを意味します。Universal Login では、SSO を含む多くのセキュリティ面およびユーザー体験面でのメリットが標準で提供されます。
Auth0 Universal Login を使用すると、ユーザー認証は短時間で簡単に行え、次の 3 つの簡単な手順で実現できます (これらはすべて Quickstarts で紹介されており、SDK が複雑さも隠蔽します) 。
  1. アプリケーションからリダイレクトする方法とタイミングを決定します。
  2. Auth0 の設定で、適切なブランディングおよび/またはカスタマイズした HTML を設定します。
  3. 認可サーバーからのレスポンスを受信して処理するようにアプリケーションを設定します。

​
username とパスワードによる認証

ほぼすべての B2C アプリケーションでは、顧客が新しい認証情報を作成できるようになっています。これは、すべてのユーザーになじみのある一般的な認証方式です。 Auth0 では、username とパスワードによる認証に複数の方法があります。アプリケーションが既存のユーザーベースを持たない新規アプリケーションであれば、Auth0 の標準の Database Connection だけで、ユーザー認証を開始するために必要なものがすべてそろいます。一方で、独自のユーザーデータベースや既存の LDAP システムなどのレガシーなユーザーストアがある場合は、User migration に関するガイダンスで説明しているように、ユーザーを移行するためのいくつかの選択肢があります。 データベース接続のユーザーをどのようにプロビジョニングする場合でも、それらのユーザーの認証方法はほぼ共通しています。必要なのは、ユーザーに username とパスワードを入力するフォームを表示することです。Universal Login に関するガイダンスでも述べたとおり、username とパスワードでユーザーを認証する最も簡単で安全な方法は、ユーザーを一元化されたログインページにリダイレクトし、そこで username とパスワードを入力してもらうことです。これにより Auth0 は、ユーザーがすでに認証済みかどうかを判断し、不要な場合はログインフォーム自体をスキップできます。

​
ベストプラクティス

認証情報を一元化されたログインページでのみ収集することで、ユーザーの秘密情報が漏えいする可能性のある箇所を減らせます。また、不要に認証情報を収集する必要も少なくなります。詳細については、Universal Login を参照してください。

​
アプリケーション統合

ユーザーをどのように認証するかが決まったら、次のステップは、その認証をどのように開始するかを決めることです。通常、アプリケーションごとに開始点は異なります。
ネイティブモバイルアプリケーション (およびデスクトップアプリケーション) では、認証にシステムブラウザーを使用する必要があります。そうしないと、追加のセキュリティリスクが生じる可能性があります。詳しくは、Native Login を参照してください。
前述のとおり、顧客向けアプリケーションでは、ほとんどのお客様が業界標準プロトコルとして OpenID Connect (OIDC) を使用しています。どの OIDC フローを使用するかを決めることが最初の作業です。まずは grant mapping に関するガイダンスを確認することをお勧めします。 アプリケーションの一部への匿名ユーザーのアクセスを許可する場合は、すぐにリダイレクトするのか、それとも必要なときにのみリダイレクトするのか (あるいはその両方を組み合わせるのか。詳しくは Redirect Users After Login を参照してください) を決める必要があります。ユーザーがサイトの保護されたバージョン (または領域) に ディープリンク できる場合は、どのアプリケーションリンクで Auth0 への自動リダイレクトが発生するかを判断する必要があります。

​
匿名アクセス

ユーザーが初めてアプリケーションを利用するときの体験を考慮することは重要です。アプリケーションが匿名ユーザーのアクセスをサポートしている場合 (e コマースアプリケーションでは非常に一般的です) 、考慮すべきシナリオはいくつかあります。
  • すでにログインしたことがあり、その後アプリケーションに戻ってきたのか、または
  • 今回初めてアプリケーションにアクセスする場合:
    • 同じ Auth0 テナントを使用している別のアプリケーションにすでにアクセスしたことがあるか、
    • このデバイスまたはブラウザーで過去に認証したことがあるか (または長期間認証していないか) 。
匿名ユーザーがアプリケーションにアクセスしたとき、同じファミリー内の別のアプリケーションにそのユーザーがすでにログインしているかどうかをアプリケーションが検出できることや、アプリケーションが状態を持たない SPA であってもそのユーザーを識別できることが望ましい場合は少なくありません。たとえば、ユーザーがすでにログインしていると判断できる場合は、アプリケーションの UI ヘッダーでログインボタンを表示せず、代わりにアカウントメニューやプロフィールメニューを表示するといった対応が考えられます。これを実現するには、“サイレント認証” を利用します。サイレント認証を使うと、ユーザーがログインしていない場合でもログインを求めることなく、ログイン済みかどうかを確認できます。その後、必要に応じてアプリケーションでログインボタンを表示できます。一方、ユーザーがすでにログインしている場合はトークンを受け取れるため、あらためてログインボタンを表示する必要はありません。
Auth0 へのリダイレクトによるログインセッションの確認はアプリケーションにとって有用ですが、その結果として大量のリクエストが発生する場合は、レイテンシーやレート制限を避けるためにスロットリングの仕組みを導入してください。Management API の呼び出しには、Auth0 のレート制限ポリシーが適用されます。この点を考慮する必要があります。また、これに対応するため、Auth0 では API を直接呼び出すのではなく、通常は開発環境に適した Auth0 SDK を使用することを推奨しています。

​
保護されたエンドポイントへのディープリンク

認証済みユーザーしかアクセスできないアプリケーション内の特定のページに、何らかの理由で直接リンクされることがあります。アプリケーションでこれが起こり得る場合は、ユーザーが未認証であれば Auth0 に自動的にリダイレクトする必要があります。認証後、 からアプリケーションに戻されたら、ユーザーを最初にアクセスしようとしていた場所へ リダイレクト できます。

​
ベストプラクティス

最近の認証フレームワークの多くは、Auth0 などの認可サーバーへリダイレクトするためのミドルウェアをサポートしています。選択する際は、次の点を考慮してください。
  • 機密クライアント、非機密クライアント、またはその両方をサポートしていること
  • ディスカバリーエンドポイント による設定、または明示的なインライン設定をサポートしていること
  • 有効期限、署名、クレーム、スコープを含むトークンの検証をサポートしていること
  • 必要に応じて、 をサポートしていること

​
ユーザーの認証

認証とは、ユーザーの本人確認を行うプロセスです。OIDCコンテキストにおける認証の結果は、です。このトークンにはユーザーに関する情報が含まれており、認可サーバーで定義された1つ以上の要素を使用してユーザーが認証した場合にのみ取得できるようにする必要があります (最も一般的な形式は、ユーザーIDとパスワードです) 。IDトークンの取得に加えて、以下の点も考慮する必要がある場合があります。
本番環境に移行する前に、各アプリケーションで使用するグラントのみが、アプリケーションの設定で有効になっていることを確認してください。

​
Authorization Code grant (PKCE の有無にかかわらず)

SDK が Authorization Code grant のみをサポートしている場合、またはアクセストークンやが必要な場合は、Authorization Code grant (PKCE の有無を問わず) を使用して IDトークンを取得することもできます。Authorization Code grant では、code をトークンに交換するための API 呼び出しが追加で必要になるため、IDトークンだけが必要な場合は、不要なレイテンシーが発生する可能性があります。多くの場合、IDトークンに最適にアクセスしつつ、Authorization Code grant のワークフローを活用してアクセストークンとリフレッシュトークンを安全に取得するために、hybrid flow が実装されます。
Auth0 では、IDトークンのみを必要とするブラウザベースのアプリケーションで implicit grant を使用できますが、PKCE を使用する authorization code grant を推奨しています。詳しくは、Auth0 Blog の OAuth2 Implicit Grant and SPA を参照してください。ユーザーを再認証することなく新しいアクセストークンまたは IDトークンを取得できるように リフレッシュトークン が必要な場合は、authorization code grant を使用する必要があります。

​
攻撃対策

認証システムが重要なのは、が、本来アクセスすべきでないアプリケーションやユーザーデータにアクセスするのを防ぐためです。そうした悪意のある攻撃者とシステムへのアクセスの間には、できるだけ多くの障壁を設ける必要があります。そのための最も簡単な方法の 1 つが、Auth0 の攻撃対策が正しく設定されていることを確認することです。このトピックに関するガイダンスを確認し、ご利用の環境で正しく機能していることを確かめてください。

​
ベストプラクティス

異常検知は Auth0 によってバックグラウンドで処理され、製品に強力なセキュリティ機能を提供します。これを利用する場合は、ユーザーへのメール配信を有効にする前に、Email Provider を設定し、Email Templates を構成しておくようにしてください。

​
レガシーシステムとの SSO

大規模な再構築では、すべてのアプリケーションを一度に更新することが、必ずしも可能または現実的とは限りません。実際、Auth0 との統合では、段階的に進めるアプローチを計画することが推奨されるベストプラクティスです。既存のアプリケーションですでにシングルサインオン (SSO) を利用しており、レガシー ID システムが OIDC や などのプロトコルをサポートしている場合は、Auth0 との統合を進めながら引き続き SSO を提供するための選択肢がいくつかあります。
  • レガシー SSO システム内の既存の IDプロバイダー を更新し、ログイン時に Auth0 にリダイレクトするようにします (例: SAML を使用) 。
  • Auth0 からレガシー SSO システムにリダイレクトしてログインさせます。これには、Auth0 でレガシーシステムを IdP として設定する必要があります (つまり、SAML または OIDC のいずれかを使用します) 。

​
ベストプラクティス

レガシーシステムで SSO をサポートすると複雑さが増す可能性はありますが、Auth0 との統合時に、よりシームレスなユーザー体験を実現するうえで有効な場合があります。この方針で進める予定であれば、早い段階から計画しておくことで、実現できる可能性を高められます。すでに一元化されたサービスで SSO を導入していない場合は、それを追加するための複雑さは、得られる利点に見合わない可能性が高いでしょう。
これは複雑なトピックであり、現在のレガシーアーキテクチャによっては追加の調査が必要になる可能性が高いため、現在のレガシーシステムで SSO をサポートしている場合にのみ検討することをお勧めします。注: 現在、アプリケーションから一元化されたシステムにリダイレクトしてユーザーを認証しており、その一元化されたシステムとのセッションがまだない場合にのみ認証情報の入力を求めるのであれば、それはレガシー SSO の実装です。

​
ソーシャル認証

Facebook や Google などが提供する「bring your own identity」のシナリオは、セキュリティを損なうことなくユーザーの認証体験を簡素化できる有効な方法です。また、Universal Login を使用すれば、最小限の変更で ソーシャル接続 のサポートを簡単に追加できます。
Auth0 では、事前設定済みの開発者キー を使用してソーシャル接続を簡単にテストできます。ただし、これらには制限事項があるため、本番環境に移行する前に、利用する各ソーシャルプロバイダーの手順に従って、アプリケーション固有のキーを設定する必要があります。
ソーシャル サポートでは、ユーザーのアイデンティティや認証情報、および一部のアイデンティティクレームはソーシャルプロバイダーによって管理されます。Auth0 はそれらを使用してユーザーのプロファイルを設定します。さらに Auth0 は、ソーシャル IDプロバイダー (Social IdP) のアクセストークンも提供できるため、アプリケーションはユーザーに代わってサードパーティの Social IdP API を呼び出すこともできます。

​
ベストプラクティス

ソーシャルログインは非常に有用な機能ですが、複数のサインイン方法を提供する場合は、顧客が実際に複数の方法を使ってサインインする可能性を考慮する必要があります。デフォルトでは、Auth0 の各ユーザーアイデンティティにはそれぞれ個別のユーザープロファイルがあるため、1 つのユーザープロファイルに複数のアイデンティティを関連付ける効果的な方法として、Auth0 のユーザーアカウントのリンク機能を検討することをお勧めします。
Auth0 のCustom Social Connections extension を使用すると、標準ではサポートされていない任意の OpenID Connect (OIDC) 準拠のサードパーティベンダーに接続でき、ソーシャル認証をさらに拡張できます。たとえば、政府発行の IDプロバイダーである SwissID のサポートは、Custom Social Connection を使用して Auth0 で設定できます。

​
多要素認証 (MFA)

ユーザー認証情報の悪用がかつてないほど増えている現在、ハッカーによるユーザーの個人情報や認証情報の窃取が一般化しており、システムを保護することは容易ではありません。そうした中でも、特に効果的な方法の 1 つが、ユーザー自身がアカウント保護のための第 2 要素を設定できるようにすることです。これは一般に 多要素認証 と呼ばれます。これにより、別のアプリケーションで漏えいした username とパスワードが使われた場合でも、正当なユーザーのみが自分のアカウントにアクセスできるようになります。

​
ベストプラクティス

顧客向けアプリケーションでは、ユーザーに第 2 要素の利用を強制するのではなく、第 2 要素を追加する選択肢を提供するのが一般的です。詳しくは、ユーザーに MFA を追加する選択肢を提供する を参照してください。
Auth0 では、ユーザーアカウントへのアクセスを保護するために MFA を有効にする複数の方法をサポートしています。また、柔軟な第 2 要素による保護を実現するために考慮すべきプラクティスもいくつかあります。
  • Auth0 Guardian: Push 通知の生成と、リクエストを許可または拒否するためのアプリケーションの両方を提供するサービスです。Push は、ユーザーが事前登録したデバイス (通常はモバイル端末またはタブレット) に通知を送信し、ユーザーはボタンを押すだけで直ちにアカウントアクセスを許可または拒否できます。
  • Time-based One-Time Password (TOTP): Google Authenticator などのデバイスを登録すると、そのデバイスが一定時間ごとに変化するワンタイムパスワードを生成し、それを第 2 要素として入力してユーザーアカウントを検証できます。
  • SMS: SMS でワンタイム code を送信し、ユーザーは認証を完了する前にその code の入力を求められます。
  • Voice: 電話でワンタイム code を伝え、ユーザーは認証を完了する前にその code の入力を求められます。
  • Duo: Duo アカウントを多要素認証に使用できます。
  • Email: メールアドレスのアカウントを多要素認証に使用できます。
Guardian や Google Authenticator などのテクノロジーを使用する MFA ワークフローは、通常、モバイル端末またはタブレット上で動作する別個のアプリケーションとして提供されます。一方で、顧客に別のアプリケーションをダウンロードさせたくない場合は、既存のモバイルアプリケーション内に第 2 要素のワークフローを直接組み込むために使用できる SDK も Auth0 で提供されています。

​
プロジェクト計画ガイド

推奨戦略の詳細を確認できるよう、ダウンロードして参照できる PDF 形式の計画ガイドを提供しています。 B2C IAM Project Planning Guide