ユーザーにサービスを提供するには、そのユーザーが誰であるかを識別できなければなりません。このプロセスをユーザー認証と呼びます。ユーザーを認証する方法には、ソーシャルメディアアカウント、ユーザー名とパスワード、 パスワードレス 多要素認証
ベストプラクティス ユーザーをどのように認証するかを設計する際は、セキュリティとユーザー体験の両方を考慮することが重要です。複数の第一要素を用意したり、認証時に複数の要素を必須にしたりすることで、その両方を実現できます。 機能やワークフローを検討する際には、考慮すべき点が数多くあります。
ユーザーはどこで資格情報を入力しますか？
ユーザーの資格情報をどのように安全に保護しますか？
認証システムをどのように運用・保守しますか？
ユーザーにパスワード認証をどのように提供しますか？
攻撃者がユーザーになりすましてログインを試みるのを、どのように防ぎますか？
さまざまな種類のアプリケーションで認証をどのように実装しますか？
異なる言語背景を持つユーザーでもログインしやすいように、どのように工夫しますか？
従来の認証システムから移行する際に、良好なユーザー体験をどのように提供しますか？
アプリケーションを Auth0 と統合する際には、何を考慮すべきですか？
多要素認証を提供する必要がありますか？
ユーザーが事前にログインする手段を持たないサービスがある場合は、どうしますか？
ある API から別の API に、同じユーザーの アクセストークン
ユーザーを組織ごとに分離する必要がある場合は、どうしますか？
ユーザーがどの組織に属しているかの識別を、どのように処理しますか？
組織向けにエンタープライズ接続を提供する利点は何ですか？
Auth0 Universal Login は、ユーザー ID とパスワードによるサインインを提供する場合でも、Social Login による、いわゆる Bring Your Own Identity のシナリオを許可する場合でも、ユーザーに安全で信頼できる体験を提供します。さらに、製品固有の ブランディング 要件がある場合でも、Universal Login 国際化 を標準でサポートしており、さらに MFA や 攻撃対策 といった Auth0 の機能もすぐに利用できるため、攻撃者がユーザーアカウントにアクセスしようとするのを防ぐための対策を講じられます。
ユーザー ID／パスワードの資格情報によるサインインを許可すると、ユーザーがシステムにアクセスする際、サードパーティのIDプロバイダー ガイダンス では、これらのオプションの活用方法を確認できます。追加の主要認証要素として、いずれかの段階でソーシャル サポートを追加すると、柔軟性が高まります。また、さまざまなソーシャルログインプロバイダー にすでに保存されている情報を活用することで、ユーザーに追加で質問することなく、より深く理解できるようになります。
既存のレガシーアイデンティティストアがある場合は、User Migration も参照してください。このセクションでは、安全性とセキュリティの面から、Auth0 のマネージド ID ストレージに移行するメリットについて説明しています。
顧客向けアプリケーションでは、OpenID OIDC ) が最も一般的に使われている業界標準プロトコルであり、Auth0 は OIDC をネイティブにサポートしています。Auth0 では、さまざまなアプリケーションを統合するための多様なアプローチを提供しているため、適切な選択に必要な情報についてはアプリケーション連携 のセクションを参照してください。
ある API から別の API を呼び出す場合や、認証済みユーザーのコンテキストが存在しない状況、たとえば 1 つ以上の cron ジョブ、レポート生成ツール、継続的インテグレーション／デリバリーシステムなどでは、userではなくapplicationを認可する仕組みが必要になります。これは 1 ステップのプロセスで、アプリケーションを (client ID machine-to-machine (m2m) authorization をご覧ください。
企業では、ユーザーを組織ごとに分けて管理する必要があることが多く、場合によってはユーザーが複数の組織にアクセスできることもあります。これらのうちどのシナリオが自社に当てはまるかを把握することで、ユーザーがどの接続に存在するかをどのように判断するか、つまりそれが必要かどうか、いつ必要になるのか、どのように実現するのかを明確にできます。これが自社に関連するかどうかを判断するには、Home Realm Discovery を参照してください。
システム内に複数のアプリケーションがありますか。あるいは、今後そうなる予定はありますか。答えが「はい」であれば、一元化されたサインイン体験が必要です。複数のアプリケーション間でシームレスな Single Sign-on
ベストプラクティス 複数のアプリケーションがある場合は、ユーザー認証のために一元化された場所 にリダイレクトするのがベストプラクティスです。Auth0 では、これは Universal Login を活用することを意味します。Universal Login には、SSO を含め、セキュリティ面とユーザー体験の両方で多くの利点が標準で備わっています。 Auth0 Universal Login を使うと、ユーザー認証は短時間で簡単に行えます。設定は 3 つの簡単な手順で完了します (すべての Quickstart でこの流れを紹介しており、SDK が複雑さも吸収してくれます) 。
アプリケーションからいつ、どのようにリダイレクトするか を決めます。Auth0 の設定で、適切な ブランディング や必要に応じてカスタマイズした HTML を設定します。
Authorization Server からのレスポンスを受信して処理する ように、アプリケーションを設定します。
ホーム レルム ディスカバリー (HRD) とは、ユーザーを認証する前に、そのユーザーがどの ID プロバイダー (または Auth0 のどの接続) に属しているかを特定するプロセスです。HRD には、次の 2 つの方法があります。
アプリケーション側で判断できるようにする
Universal Login ページで Home Realm Discovery を行う
システムによっては、これらのいずれか一方、または両方の方法が必要になる場合があります。そのため、HRD のすべてのアプローチを理解し、アプリケーションに最も適した方法を適用できるようにしておくことが重要です。
ユーザーがどのレルムに属しているかを判断する一般的な方法の 1 つは、組織ごとにアプリケーションをブランド分けすることです。通常、この場合は各組織ごとにアプリケーションの専用インスタンスがあり、別々の URL からアクセスします。このコピーまたはインスタンスは、物理的に分離されている場合 (別々のサーバー群で稼働) もあれば、仮想的に分離されている場合 (共有サーバー上で稼働) もあります。一般的には、カスタムホスト名 (companyA.application1.yourcompany.com) またはパス (application1.yourcompany.com/companyA) で区別されます。
ベストプラクティス アプリケーションが必要な特定の接続 (IdP) をすでに把握している場合は、ユーザーを /authorize にリダイレクトする際に、connection クエリパラメータを使ってその情報を渡すこともできます。 アプリケーションがこのケースに当てはまる場合、ホームレルムディスカバリーは、組織固有のアプリケーション設定に org_id を保存し、ユーザーを Universal Login にリダイレクトする際に、それを organization パラメータとして送信するだけで簡単に実現できます。これにより、ユーザーはその特定の組織と、その組織に設定された接続に限定されます。
ベストプラクティス 組織で複数の IdP が必要な場合は、ホームレルムディスカバリーをもう 1 回行う必要が生じることがあります (組織が特定された後) 。Organizations Feature を使用している場合は、通常 Auth0 がこれを処理します。 ユーザーが単一の ID を使って複数の組織で共有されている場合は、Universal Login ページでのホームレルムディスカバリー をサポートする必要があります。これにより、Universal Login でまずユーザーを特定し、その後、そのユーザーに適したレルムを提示できるため、より良いユーザー体験につながります。
organization パラメータや connection パラメータは、ユーザーを /authorize エンドポイントにリダイレクトする際に、クエリパラメータとして追加することで送信できます。詳しくは、Authentication API docs を参照してください。ただし通常は、アプリケーションの実装言語に対応した SDK を使ってこれを行います。
ホームレルムディスカバリー には、主に 3 つのアプローチがあります。
ユーザーのメールアドレスのサブドメインからレルムを特定する。
識別子とレルムの対応表のようなものを使ってユーザー識別子を参照し、レルムを特定する。
ユーザーが自分のレルム (または組織) を選択または入力できるようにする。
最初の 2 つのアプローチでは、“Identifier First Login” の採用を検討できます。これは、最初に識別子のみを入力できるようにする方式です。その後、ユーザーの識別子を取得し、その識別子に基づいて、ユーザーを自動的にリダイレクトするか、リダイレクトが不要な場合はパスワード入力画面を表示します。Auth0 では、Universal Login を使ってこれらすべてに対応できる実装が標準で提供されています。
Identifier First Login を実装したり、Universal Login Page ではなくアプリケーション側でユーザーに組織を選択させたりすることは可能ですが、その場合、シングルサインオンに関する複雑さに加え、その動作をすべてのアプリケーションで再現するための複雑さも増します。そのため Auth0 では、代わりに Universal Login を使った何らかの形の HRD を実装することを推奨しています。
メールのサブドメインを使用した Universal Login での HRD ユニバーサルログインページでホームレルムディスカバリーを実装する最も簡単な方法は、ユーザー識別子に含まれるメールのサブドメインを利用して、対応する Identity Provider にマッピングすることです。もちろん、これはメールのサブドメインが組織、または少なくとも Identity Provider と 1 対 1 で対応している場合にのみ機能します。
エンタープライズ接続でドメインマップを使用している場合は、Auth0 の Lock ウィジェットまたは Universal Login でこれを実現できます。ただし、これを独自に構築することも可能ですが、その場合はメールのサブドメインから接続へのマッピングを自分で作成する必要があります。
さらに、Universal Login エクスペリエンスを使用する場合、Organizations Feature は次の 2 つの点で役立ちます。
ログインリクエストの開始時に /authorize に org_id を渡していない場合、Auth0 はユーザーに対して、自分が所属する組織を入力するよう求めるプロンプトを表示します。
その Organization に複数の IdP が関連付けられている場合、Auth0 はユーザーに対して、組織を選択するためのボタン、またはユーザー名とパスワードを入力するフォームを表示します。
Identifier to Realm Map を使用した Universal Login での HRD 2 つ目の、より複雑な方法として、識別子と IdP の対応マップを保存し、その情報にアクセスするための公開エンドポイントを提供する方法があります。そうすると、Universal Login ページで接続先を特定し、connection を付けて /authorize にリダイレクトし直すことができます。この方法の主な欠点は遅延です。さらに重要なのは、識別子の特定に関わるセキュリティ上の問題です。メールアドレスを使用している場合、特定のメールアドレスがあなたのユーザーかどうかを第三者がはるかに簡単に突き止められるようになります。
ベストプラクティス 公開エンドポイントには、ハッカーによる情報探索への悪用を防ぎ、サービス拒否攻撃を防止するために、必ずレート制限を適用してください。 ユーザー選択を使った Universal Login による HRD もう 1 つの方法は、ユーザーが一覧から選択できるようにすることです。これは、製品を利用している組織の一覧を公開しても問題ない場合に使えます。あるいは、ユーザーが自分の組織名を直接入力できるようにすることもできます。通常は、ユーザーを Universal Login にリダイレクトする前にこれを行います。ユーザーが所属する組織を指定したら、その組織の接続を指定して Auth0 にリダイレクトできます。接続がデータベース接続の場合は、Auth0 がユーザーにユーザー名とパスワードの入力を求めるだけにすることもできます。
ほぼすべての B2C アプリケーションでは、顧客が新しい認証情報を作成できるようになっています。これは、あらゆるユーザーになじみのある一般的な認証方式です。
Auth0 では、ユーザー名とパスワードによる認証を複数の方法で実装できます。既存のユーザーベースを持たない新規開発のアプリケーションであれば、Auth0 の標準機能であるシンプルな Database Connection を使うだけで、ユーザー認証を始めるために必要なものがすべて揃います。一方、レガシーなユーザーストア (独自のユーザーデータベースや既存の LDAP システムなど) がある場合は、User migration に関するガイダンスで説明しているように、ユーザーを移行するための選択肢がいくつかあります。
どのような方法でデータベース接続のユーザーを用意する場合でも、それらのユーザーの認証方法はほぼ共通です。ユーザーには、ユーザー名とパスワードを入力するフォームを提示する必要があります。Universal Login に関するガイダンスでも述べたように、ユーザー名とパスワードでユーザーを認証する最もシンプルで安全な方法は、一元化されたログインページにリダイレクトし、そこでユーザー名とパスワードを入力してもらうことです。これにより Auth0 は、ユーザーがすでに認証済みかどうかを判断し、不要な場合はログインフォーム自体を省略できます。
ベストプラクティス 認証情報を一元化されたログインページでのみ収集することで、ユーザーの秘密情報が漏洩する可能性のある箇所を減らせます。また、不要な認証情報の収集も抑えられます。詳しくは Universal Login を参照してください。 ユーザーをどのように認証するかが決まったら、次はその認証をどのように開始するかを決めます。通常、アプリケーションごとに独自の開始ポイントがあります。
ネイティブモバイルアプリケーション (およびデスクトップアプリケーション) では、認証にシステムブラウザーを使用する必要があります。そうしないと、追加のセキュリティリスクが生じる可能性があります。詳しくは Native Login を参照してください。 前述のとおり、お客様向けアプリケーションでは、当社の顧客の大半が業界標準プロトコルとして OpenID Connect (OIDC) を利用しています。まず最初に行うべきことは、どの OIDC flow を使用するかを決めることです。その際は、まず grant mapping に関するガイダンスを確認することをお勧めします。
匿名ユーザーにアプリケーションの一部へのアクセスを許可したい場合は、すぐにリダイレクトするのか、それとも必要になったときにだけリダイレクトするのか (あるいはその両方を組み合わせるのか。詳しくは Redirect Users After Login を参照してください) を判断する必要があります。ユーザーがサイト内の保護されたバージョン (または領域) へ deep link できる場合は、どのアプリケーションリンクで Auth0 への自動リダイレクトを発生させるかを決める必要があります。
ユーザーが初めてアプリケーションを利用する際の体験を考慮することは重要です。アプリケーションが匿名ユーザーによるアクセスをサポートしている場合 (e コマースアプリケーションでは非常に一般的です) 、考慮すべきシナリオがいくつかあります。
すでにログインしたことがあり、その後アプリケーションに戻ってきたのか、あるいは
今回がそのアプリケーションへの初回アクセスである場合:
同じ Auth0 tenant を使用する別のアプリケーションに、すでにアクセスしたことがあるか
このデバイスまたはブラウザーで認証したことがあるか (または、長い間認証していないか)
匿名ユーザーがアプリケーションにアクセスした際、同じファミリー内の別のアプリケーションにそのユーザーがすでにログインしているかどうかをアプリケーションで検出できるようにしたり、アプリケーションが状態を持たない SPA であってもそのユーザーを記憶できるようにしたりすることが望ましい場合がよくあります。たとえば、ユーザーがすでにログインしていると判断できるなら、アプリケーションの UI ヘッダーではログインボタンを表示せず、代わりにユーザー向けのアカウントメニューやプロフィールメニューを表示するようにするかもしれません。これを実現するには、“サイレント認証 ” を利用します。サイレント認証を使うと、ユーザーがログインしていない場合でもログインを求めることなく、ログイン済みかどうかを確認できます。そのうえで、必要に応じてアプリケーションでログインボタンを表示できます。一方、ユーザーがすでにログインしている場合はトークンを受け取れるため、あらためてログインボタンを表示する必要はありません。
Auth0 にリダイレクトしてログインセッションを確認することは、アプリケーションにとって有用ですが、その結果多数のリクエストが発生する場合は、遅延やレート制限を避けるためにスロットリングの仕組みを導入する必要があります。 Management API の呼び出しには、Auth0 Rate Limiting policy が適用されます。この点を考慮する必要があります。また、Auth0 では通常、API を直接呼び出すのではなく、開発環境に適した Auth0 SDK を使用することを推奨しています。 認証済みユーザーしかアクセスできないアプリケーション内の特定のページに、誰かが直接リンクする理由はさまざまです。アプリケーションでこれが可能な場合、ユーザーが未認証であれば、自動的に Auth0 にリダイレクトする必要があります。ユーザーの認証が完了し、認可サーバー リダイレクトできます 。
現在主流の認証フレームワークの多くは、Auth0 のような認可サーバーへのリダイレクトに対応するミドルウェアをサポートしています。選定する際は、次の重要な点を考慮してください。
機密クライアント、非機密クライアント、またはその両方に対応していること
discovery endpoint を使用した設定、または明示的にインラインで設定できること有効期限、署名、クレーム、スコープを含むトークン検証に対応していること
必要に応じて、Refresh Tokens
認証とは、ユーザーの本人確認を行うプロセスです。OIDC における認証の結果は、ID Token ユーザー ID とパスワード です) 。ID Token の取得に加えて、次の点についても考慮が必要になる場合があります。
本番環境に移行する前に、各アプリケーションで使用するグラントのみ が、アプリケーションの設定 で有効になっていることを確認してください。 お使いの SDK が Authorization Code grant のみをサポートしている場合、または Access Token や Refresh Token PKCE の有無を問わず) を使用して ID Token を取得することもできます。Authorization Code grant では、コードをトークンに交換するための追加の API 呼び出しが必要になるため、ID Token だけが必要な場合は、不必要な待ち時間が増える可能性があります。多くの場合、ID Token への最適なアクセスを実現しつつ、Authorization Code grant のワークフローを活用して Access Token と Refresh Token を安全かつ確実に取得できるようにするため、hybrid flow が実装されます。
認証システムが重要なのは、悪意ある行為者 攻撃対策 が正しく設定されていることを確認することです。少し時間を取ってこのトピックに関するガイダンスを読み、ご利用の環境で正しく機能していることを確認してください。
大規模な再構築では、すべてのアプリケーションを一度に更新することが、常に可能または現実的とは限りません。実際、Auth0 との統合では、段階的に進めるアプローチを計画することが、推奨されるベストプラクティスです。アプリケーションがすでにシングルサインオン (SSO) に対応しており、かつレガシー ID システムが OIDC や SAML
レガシー SSO システム内の既存の ID プロバイダーを更新し、ログイン時に Auth0 にリダイレクトするようにする (例: SAML を使用) 、または
Auth0 からレガシー SSO システムにリダイレクトしてログインさせる。この場合、レガシーシステムを Auth0 の IdP として設定する必要があります (つまり、SAML または OIDC を使用) 。
ベストプラクティス レガシーシステムでの SSO エクスペリエンスをサポートすると複雑さが増す可能性はありますが、Auth0 との統合時に、よりシームレスなユーザー体験を実現するうえで価値がある場合があります。この方法を採る予定であれば、早い段階で計画しておくことで、実現できる可能性が高まります。すでに一元化されたサービスで SSO を提供していない場合は、それを追加するための複雑さは、得られるメリットに見合わない可能性が高いでしょう。 これは複雑なトピックであり、現在のレガシーアーキテクチャによっては追加の調査が必要になる可能性が高いため、現在レガシーシステムで SSO をサポートしている場合にのみ検討することをお勧めします。注: 現在、アプリケーションからユーザーを認証するために一元化されたシステムへリダイレクトしており、そのシステムとのセッションがまだない場合にのみ認証情報の入力を求めるのであれば、それはレガシー SSO の実装です。
「bring your own identity」の考え方は、今やほぼすべての B2B アプリケーションで不可欠な要件になっています。多くのエンタープライズ企業は、従業員が新たに認証情報を管理しなくて済むよう、自社の IdP をアプリケーションに統合できることを期待しています。これは、セキュリティを損なうことなくユーザー認証の体験を簡素化できる有効な方法です。さらに、Universal Login を使えば、Enterprise Connections のサポート追加も最小限の影響で簡単に始められます。
ベストプラクティス ユーザー向けにエンタープライズ接続をサポートし始めたら、認証時にどの接続先へユーザーを誘導するかを判断できるよう、何らかの形で ホームレルムディスカバリー を必ず実装する必要があります。 エンタープライズ接続をサポートすると、ユーザーの ID や認証情報は顧客組織の ID プロバイダーによって管理されます。また、特定の ID クレームもそこで管理され、Auth0 はそれらを使用してユーザーの profile を構成します。
ベストプラクティス 「Bring your own identity」は非常に有用な機能ですが、これを初日からサポートしていない場合はもちろん、サポートしている場合でも、しばらくアプリケーションを利用した後に自社の IdP へ切り替えたいと考える組織が出てくることがあります。そのため、新しい ID を既存のデータベース ID に適切に関連付けられるよう、ユーザーアカウントのリンク を行う手段を用意する必要があります。 ユーザー認証情報の悪用がかつてないほど増えている現在、ハッカーによるユーザーの本人確認情報の窃取も日常的に起きており、システムを保護するのは簡単ではありません。そうした中でも、特に効果的な方法の 1 つが、ユーザー自身でアカウント保護のための第 2 要素を設定できるようにすることです。一般には 多要素認証 と呼ばれます。これにより、たとえ別のアプリケーションから漏えいしたユーザー名とパスワードが使われた場合でも、正当なユーザー本人だけがアカウントにアクセスできるようになります。
ベストプラクティス 顧客向けアプリケーションでは、第 2 要素の利用を必須 にするのではなく、ユーザーが第 2 要素を追加できる選択肢 として提供することがよくあります。詳しくは、ユーザーに MFA を追加する選択肢を提供する を参照してください。 Auth0 は、ユーザーアカウントへのアクセスを保護するために MFA を有効にする際のさまざまな方法をサポートしており、柔軟な第 2 要素によるアクセス保護を実現するための実践方法もいくつかあります。
Auth0 Guardian : Push 通知の生成と、リクエストを許可または拒否するためのアプリケーションの両方を提供するサービスです。Push は、ユーザーが事前登録したデバイス (通常はスマートフォンまたはタブレット) に通知を送信し、ユーザーはボタンを押すだけで直ちにアカウントへのアクセスを許可または拒否できます。
時間ベースのワンタイムパスワード (TOTP ) : Google Authenticator などのデバイスを登録し、一定時間ごとに変化するワンタイムパスワードを生成して、第 2 要素として入力することでユーザーアカウントを検証できます。
SMS: SMS でワンタイムコードを送信し、ユーザーは認証を完了する前にそのコードの入力を求められます。
音声: 電話でワンタイムコードを通知し、ユーザーは認証を完了する前にそのコードの入力を求められます。
Duo: Duo アカウントを多要素認証に利用できます。
Email: メールアカウントを多要素認証に利用できます。
Guardian や Google Authenticator のような技術を使った MFA ワークフローは、通常、モバイル端末やタブレット上で動作する別アプリケーションを通じて提供されますが、顧客に別アプリケーションをダウンロードしてもらいたくない場合は、Auth0 が提供する SDK を使って、既存のモバイルアプリケーションに第 2 要素のワークフローを直接組み込むこともできます。
推奨戦略の詳細を確認できるよう、PDF形式の計画ガイドをご用意しています。ダウンロードしてご参照ください。
B2B IAM プロジェクト計画ガイド 多くのB2Bプラットフォームでは、顧客ごとに組織の分離やブランディングを何らかの形で実装しており、その結果、Identity and Access Management (IAM) システムが複雑になることがあります。これに当てはまる場合は、このような環境向けのガイダンスやベストプラクティスについて、ぜひ一度ご確認ください。
複数組織アーキテクチャ 
認証
ユーザー管理
カスタマイズ
プラットフォーム