ユーザーにサービスを提供するには、そのユーザーが誰であるかを識別できなければなりません。このプロセスはユーザー認証と呼ばれます。ユーザーを認証する方法はいくつもあり、ソーシャルアカウント、username とパスワード、パスワードレス 多要素認証
ベストプラクティス ユーザーをどのように認証するかを設計する際は、セキュリティとユーザーエクスペリエンスの両方を考慮することが重要です。複数の第1要素を提供することや、認証時に複数の要素を必須にすることは、その両方を実現する方法です。 機能やワークフローを検討する際には、考慮すべき点がいくつもあります。
ユーザーはどこで認証情報を入力しますか？
ユーザーの認証情報をどのように安全に保ちますか？
認証システムをどのように維持しますか？
ユーザーにパスワード認証をどのように提供しますか？
攻撃者がユーザーになりすましてログインしようとするのをどのように防ぎますか？
さまざまな種類のアプリケーションで認証をどのように実装しますか？
異なる言語背景を持つユーザーに対して、ログインをどのように容易にしますか？
レガシー認証システムから移行する際に、どのように優れたユーザーエクスペリエンスを提供しますか？
アプリケーションを Auth0 と統合する際に、何を考慮すべきですか？
多要素認証を提供する必要がありますか？
ユーザーが事前にログインする手段を持たないサービスがある場合、どうしますか？
同じユーザーのアクセストークン
ユーザーを組織ごとに分離する必要がある場合、どうしますか？
ユーザーがどの組織に属しているかをどのように識別しますか？
組織向けにエンタープライズ接続を提供するメリットは何ですか？
Auth0 の Universal Login は、ユーザー名/パスワード認証情報によるサインインを提供する場合でも、Social Login による、いわゆる Bring Your Own Identity のシナリオを許可する場合でも、ユーザーに安全で安心な体験を提供します。さらに、製品固有のブランディング 要件がある場合でも、Universal Login 国際化 も標準でサポートしています。また、MFA や 攻撃対策 といった Auth0 の機能も標準でサポートされているため、攻撃者がユーザーアカウントにアクセスしようとするのを防ぐための障壁を設けることができます。
ユーザー名/パスワード認証情報でのサインインを許可すると、ユーザーがシステムにアクセスする際に、サードパーティのIDプロバイダー 提供されるガイダンス によって、これらのオプションをどのように活用できるかを理解できます。さらに、追加の第1認証要素として、ある段階でsocial サポートを追加すると柔軟性が高まり、各種ソーシャルログイン providers にすでに保存されている情報を活用して、追加で質問しなくてもユーザー理解を深めるのに役立ちます。
既存のレガシーなアイデンティティストアがある場合は、User Migration も参照してください。このセクションでは、安全性とセキュリティの観点から、Auth0 のマネージドアイデンティティストレージへ移行する利点について説明します。
顧客向けアプリケーションでは、OpenID OIDC ) が最も一般的に使用される業界標準プロトコルであり、Auth0 は OIDC をネイティブにサポートしています。Auth0 はさまざまなアプリケーションを統合するための複数のアプローチをサポートしているため、適切な選択を行うために必要な情報については、application integration のセクションを参照してください。
ある API から別の API を呼び出す場合や、認証済みユーザーのコンテキストが存在しない状況 (たとえば、1 つ以上の cron ジョブ、レポートジェネレーター、継続的インテグレーション/デリバリーシステムなど) では、ユーザーではなくアプリケーションを認可する方法が必要になります。これは 1 ステップのプロセスで、アプリケーションを認証し (クライアントID machine-to-machine (m2m) authorization を参照してください。
多くの企業では、ユーザーを組織ごとに分離する必要があり、ユーザーが複数の組織にアクセスできる場合もあります。自社に該当するシナリオを把握することで、ユーザーがどの接続に存在するかを判断する方法、つまりそれが必要かどうか、いつ必要になるか、どのように実現するかを明確にできます。これが自社に関連するかどうかを判断するには、Home Realm Discovery を参照してください。
システム内に複数のアプリケーションがある、または今後増える予定はありますか。答えが「はい」であれば、一元化されたサインイン体験が必要です。複数のアプリケーション間でシームレスなシングルサインオン
ベストプラクティス 複数のアプリケーションがある場合は、ユーザーを認証するために一元化された場所 へリダイレクトするのがベストプラクティスです。Auth0 では、これは Universal Login を活用することを意味します。Universal Login では、SSO を含む多くのセキュリティ面およびユーザー体験面の利点を、そのまま利用できます。 Auth0 Universal Login を使用すると、ユーザー認証は短時間で簡単に行え、次の 3 つの手順で実現できます (すべての Quickstarts でこれを実演しており、SDK によって複雑さも隠蔽されます) 。
アプリケーションからリダイレクトする 方法とタイミングを決定します。Auth0 の設定で、適切なブランディング および/またはカスタマイズした HTML を設定します。
認可サーバーからの応答を受信して処理する ようにアプリケーションを設定します。
ホーム レルム ディスカバリー (HRD) は、ユーザーを認証する前に、そのユーザーがどのIDプロバイダー (または Auth0 のどの接続) に属しているかを特定するプロセスです。HRD は次の 2 つの方法で実行できます。
アプリケーション側で判定できるようにする
Universal Login ページでホーム レルム ディスカバリーを行う
システムによっては、これらの方法のいずれか一方、または両方が必要になる場合があります。そのため、アプリケーションに最も適した方法を適用できるよう、HRD の各アプローチを理解しておくことが重要です。
ユーザーがどのレルムに属するかを判断する一般的な方法の 1 つは、アプリケーションが組織ごとにブランド化されているケースです。この場合、通常は各組織がアプリケーションの専用インスタンスを持ち、異なる URL からアクセスします。このコピーまたはインスタンスは、物理的に分離されている場合 (別個のサーバー群で稼働) もあれば、仮想的に分離されている場合 (共有サーバー上で稼働) もあり、一般にはカスタムホスト名 (companyA.application1.yourcompany.com) またはパス (application1.yourcompany.com/companyA) で表されます。
ベストプラクティス アプリケーションが必要な特定の接続 (IdP) をすでに把握している場合は、ユーザーを /authorize にリダイレクトする際に、connection クエリパラメーターを使ってそれを渡すこともできます。 アプリケーションがこのケースに当てはまる場合、ホーム レルム ディスカバリーは、組織固有のアプリケーション設定に org_id を保存し、ユーザーを Universal Login にリダイレクトするときにそれを organization パラメーターとして送信するだけで実現できます。これにより、ユーザーはその特定の組織と、その組織に設定された接続のセットに限定されます。
ベストプラクティス 組織で複数の IdP が必要な場合は、ホーム レルム ディスカバリーをもう一度実行しなければならないことがあります (組織を特定した後) 。Organizations Feature を使用している場合は、通常、Auth0 がこれを管理します。 単一の ID を使うユーザーが複数の組織にまたがって共有される場合は、Universal Login ページでの ホーム レルム ディスカバリー をサポートする必要があります。これにより、Universal Login は最初にユーザーを特定し、その後でそのユーザーに適したレルムを提示できるため、より良いユーザー体験を提供できます。
organization パラメーターや connection パラメーターは、ユーザーを /authorize エンドポイントにリダイレクトする際にクエリパラメーターとして追加することで送信できます。詳細については、Authentication API ドキュメント を参照してください。ただし、通常は、アプリケーションで使用している言語向けの SDK を使ってこれを行います。
ホーム レルム ディスカバリーには、主に 3 つの方法があります。
ユーザーのメールアドレスのサブドメインからレルムを特定する。
識別子とレルムの対応表のようなマップを使って、ユーザー識別子からレルムを特定する。
ユーザー自身がレルム (または組織) を選択または入力できるようにする。
最初の 2 つの方法では、「Identifier First Login」を検討できます。これは、最初に識別子だけを入力させる方式です。その後、取得したユーザー識別子に基づいて、ユーザーを自動的にリダイレクトするか、リダイレクトが不要な場合はパスワード入力に進ませます。Auth0 では、Universal Login を使用して、これらを処理するための実装が標準で提供されています。
Identifier First Login を実装したり、Universal Login Page ではなくアプリケーション側でユーザーに組織を選択させたりすることは可能です。ただし、その場合は SSO (シングルサインオン) に関する複雑さに加え、その動作をすべてのアプリケーションで再現するための複雑さも増します。そのため Auth0 では、代わりに Universal Login を通じて何らかの形で HRD を実装することを推奨しています。
メールアドレスのサブドメインを使用した Universal Login による HRD Universal Login ページでホームレルムディスカバリーを実装する最も簡単な方法は、ユーザーの識別子に含まれるメールアドレスのサブドメインを使って、対応する IDプロバイダーにマッピングすることです。もちろん、これはメールアドレスのサブドメインが組織、または少なくとも IDプロバイダーと 1:1 で対応している場合にのみ機能します。
Auth0 の Lock ウィジェットまたは Universal Login では、エンタープライズ接続でドメインマップを使用している場合、この処理を行えます。ただし、これを独自に実装することも可能ですが、その場合はメールアドレスのサブドメインから接続へのマッピングを作成する必要があります。
さらに、Universal Login エクスペリエンスを使用する場合、Organizations Feature は次の 2 つの点で役立ちます。
ログインリクエストの開始時に /authorize に org_id を渡していない場合、Auth0 はユーザーに所属する組織の入力を求めるプロンプトを表示します。
組織に複数の IdP が関連付けられている場合、Auth0 はユーザーに対して、組織を選択するためのボタン、または username と password を入力するフォームを表示します。
Identifier to Realm Map を使用した Universal Login 経由の HRD 2 つ目の、より複雑な代替案として、識別子と IdP の対応マップを保存し、その情報にアクセスするための公開エンドポイントを提供する方法があります。次に、Universal Login ページで接続を特定し、その接続を付けて /authorize にリダイレクトできます。この方法の主な欠点は、レイテンシと、さらに重要な点として、識別子の発見に関するセキュリティです。メールアドレスを使用している場合、これにより、特定のメールアドレスが自社のユーザーかどうかを第三者がはるかに容易に突き止められるようになります。
ベストプラクティス 公開エンドポイントには、攻撃者による情報の特定やサービス拒否攻撃を防ぐため、必ずレート制限を適用してください。 ユーザー選択を使用した Universal Login 経由の HRD もう 1 つの方法は、一覧から選択させる方法です。これは、自社製品を利用している組織の一覧を公開しても問題ない場合や、ユーザーが自分の組織名を明示的に入力できるようにする場合に適しています。通常、これはユーザーを Universal Login にリダイレクトする前に行います。ユーザーが所属する組織を指定したら、その組織の接続を指定して Auth0 にリダイレクトできます。また、接続がデータベース接続であれば、Auth0 に username とパスワードの入力を求めさせることもできます。
ほぼすべての B2C アプリケーションでは、顧客が新しい認証情報を作成できます。これは、すべてのユーザーになじみのある一般的な認証方式です。
Auth0 では、username とパスワードによる認証に複数の方法があります。アプリケーションが既存のユーザーベースを持たない新規開発のアプリケーションであれば、シンプルな Auth0 標準の データベース接続 だけで、ユーザー認証を開始するために必要なものがすべて揃います。一方、レガシーなユーザーストア (独自のユーザーデータベースや既存の LDAP システムなど) がある場合は、ユーザー移行 に関するガイダンスで説明しているように、ユーザーを移行するための選択肢がいくつかあります。
データベース接続にユーザーをどのようにプロビジョニングする場合でも、それらのユーザーの認証方法はほぼ同じです。ユーザーに、username とパスワードを入力するフォームを表示する必要があります。Universal Login に関するガイダンスでも述べたとおり、username とパスワードでユーザーを認証する最も簡単で安全な方法は、一元化されたログインページにリダイレクトし、そこで username とパスワードを入力してもらうことです。これにより Auth0 は、ユーザーがすでに認証済みかどうかを判断し、不要な場合はログインフォーム自体を省略できます。
ベストプラクティス 認証情報を一元化されたログインページでのみ収集することで、ユーザーの機密情報が漏えいする可能性のある範囲を縮小できます。また、不要な認証情報の収集も減らせます。詳細については、Universal Login を参照してください。 ユーザーをどのように認証するかを決めたら、次のステップは、その認証をどのように開始するかを決めることです。通常、アプリケーションごとに開始地点は異なります。
ネイティブモバイルアプリケーション (およびデスクトップアプリケーション) では、認証にシステムブラウザーを使用する必要があります。そうしないと、セキュリティリスクが増大するおそれがあります。詳細については、Native Login を参照してください。 前述のとおり、顧客向けアプリケーションでは、ほとんどのお客様が業界標準プロトコルとしてOpenID Connect (OIDC) を使用しています。どのOIDCフローを使用するかを判断することが最初の作業です。まずはgrant mapping に関するガイダンスを確認することをお勧めします。
匿名ユーザーにアプリケーションの一部へのアクセスを許可する場合は、すぐにリダイレクトするのか、それとも必要になったときだけリダイレクトするのか (あるいはその両方を組み合わせるのか。詳しくはRedirect Users After Login を参照) を決める必要があります。ユーザーがサイトの保護されたバージョン (または領域) にディープリンク できる場合は、Auth0 への自動リダイレクトが発生するアプリケーション内のリンクを特定する必要があります。
ユーザーが初めてアプリケーションを訪れたときの体験を考慮することは重要です。アプリケーションが匿名ユーザーのアクセスをサポートしている場合 (e コマースアプリケーションでは非常に一般的です) 、考慮すべきシナリオがいくつかあります。
そのユーザーは、すでにログインしたことがあり、再びアプリケーションに戻ってきたのか、あるいは
今回が初めてアプリケーションにアクセスする場合は:
同じ Auth0 テナントを使用する別のアプリケーションに、すでにアクセスしたことがあるか
このデバイスまたはブラウザーで認証したことがあるか (あるいは長期間認証していないか)
匿名ユーザーがアプリケーションにアクセスしたとき、同じファミリー内の別のアプリケーションにそのユーザーがすでにログインしているかどうかをアプリケーションが検出したり、アプリケーションが state を持たない SPA であってもそのユーザーを識別できたりすることが望ましい場合は少なくありません。たとえば、ユーザーがすでにログインしていると判断できるなら、アプリケーションの UI ヘッダーではログインボタンを表示せず、代わりにアカウントメニューやプロフィールメニューを表示するようにできます。これを実現するには、“サイレント認証 ” を利用します。サイレント認証を使用すると、ユーザーがログインしていない場合でもログインを求めることなく、ログイン済みかどうかを確認できます。必要であれば、その後でアプリケーションにログインボタンを表示できます。一方、ユーザーがすでにログインしている場合はトークンを受け取れるため、ログインボタンを再度表示する必要はありません。
Auth0 にリダイレクトしてログインセッションを確認することはアプリケーションにとって有用ですが、その結果として多数のリクエストが発生する場合は、レイテンシーやレート制限を避けるためにスロットリングの仕組みを導入してください。 Management API の呼び出しには Auth0 のレート制限ポリシー が適用されます。この点を考慮する必要があります。また、そのための支援として、Auth0 では API を直接呼び出すのではなく、開発環境に適した Auth0 SDK を使用することを一般的に推奨しています。 認証済みユーザーのみがアクセスできるアプリケーション内の特定のページに、ユーザーが直接リンクする理由はさまざまです。アプリケーションでこれが可能な場合は、ユーザーが未認証であれば自動的に Auth0 にリダイレクトする必要があります。ユーザーの認証が完了し、認可サーバー リダイレクト できます。
最近の認証フレームワークの多くは、Auth0 などの認可サーバーへのリダイレクトを行うミドルウェアをサポートしています。選定する際は、次の点を確認してください。
機密クライアント、非機密クライアント、またはその両方に対応していること
ディスカバリーエンドポイント を使った設定、または明示的なインライン設定に対応していること有効期限、署名、クレーム、スコープを含むトークンの検証に対応していること
必要に応じて リフレッシュトークン
認証とは、ユーザーの本人確認を行うプロセスです。OIDC のコンテキストでは、認証の結果として IDトークン ユーザー ID とパスワード です) 。また、IDトークンを取得する以外に、次の点も考慮する必要がある場合があります。
本番環境に移行する前に、各アプリケーションで使用するグラントのみ が、アプリケーションの設定 で有効になっていることを確認してください。 使用している SDK が認可コードグラントのみをサポートしている場合、またはアクセストークンや リフレッシュトークン PKCE の有無を問わず) を使用して IDトークンを取得することもできます。認可コードグラントでは、code をトークンと交換するための追加の API 呼び出しが必要になるため、IDトークンだけが必要な場合には不要なレイテンシーが発生することがあります。多くの場合、IDトークンへの最適なアクセスを実現しつつ、認可コードグラントのワークフローを活用してアクセストークンとリフレッシュトークンを安全に取得するために、ハイブリッドフロー が実装されます。
認証システムが重要なのは、悪意のある攻撃者 攻撃対策 が正しく設定されていることを確認することです。このトピックに関するガイダンスを確認し、意図したとおりに機能していることを確かめてください。
大規模な再編成では、すべてのアプリケーションを一度に更新できるとは限らず、現実的でない場合もあります。実際、Auth0 との統合は、反復的に進めるアプローチで計画することをベストプラクティスとして推奨しています。アプリケーションですでにシングルサインオン (SSO) を利用しており、レガシー ID システムが OIDC や SAML
レガシー SSO システム内の既存の IDプロバイダーを更新し、ログイン時に Auth0 にリダイレクトする (例: SAML を使用) 、または
Auth0 からレガシー SSO システムにリダイレクトしてログインさせる。この場合は、レガシーシステムを Auth0 で IdP として設定する必要があります (つまり、SAML または OIDC を使用します) 。
ベストプラクティス レガシーシステムで SSO エクスペリエンスをサポートすると複雑さは増しますが、Auth0 との統合時によりシームレスなユーザー体験を実現するうえで価値がある場合があります。この方法を採用する予定であれば、早い段階で計画しておくことで、実現可能性を確保しやすくなります。まだ一元化されたサービスで SSO を提供していない場合は、それを追加する複雑さは、得られるメリットに見合わない可能性が高いでしょう。 これは複雑なトピックであり、現在のレガシーアーキテクチャによっては追加の調査が必要になる可能性があります。そのため、この方法を検討するのは、現在レガシーシステムで SSO をサポートしている場合のみにすることを推奨します。注: 現在、アプリケーションから一元化されたシステムへリダイレクトしてユーザーを認証し、その一元化されたシステムとのセッションがすでにある場合は認証情報の入力を求められないのであれば、それはレガシー SSO の実装です。
「自社の ID 基盤を利用する」というシナリオは、ほぼすべての B2B アプリケーションで必須になっています。多くの企業では、従業員が別途認証情報を保持しなくて済むように、自社の IdP をアプリケーションに統合できることを期待しています。これは、セキュリティを損なうことなくユーザー認証体験を簡素化する有効な方法です。また、Universal Login を使用すると、最小限の影響で エンタープライズ接続 のサポート追加を簡単に開始できます。
ベストプラクティス ユーザー向けにエンタープライズ接続のサポートを開始したら、認証のためにユーザーをどの接続に送るかを判断できるよう、何らかの形で ホーム レルム ディスカバリー を実装する必要があります。 エンタープライズ接続をサポートすると、ユーザーの ID や認証情報、および一部の ID クレームは、顧客の組織の IDプロバイダーによって管理されます。Auth0 はそれらを使用して、ユーザーの プロフィール を構成します。
ベストプラクティス 「自社の ID 基盤を利用する」機能は非常に有用ですが、初日からこれをサポートしていない場合や、場合によってはサポートしている場合でも、しばらくアプリケーションを利用した後で独自の IdP に切り替えたいと考える組織が現れることがあります。新しい ID を既存のデータベース ID に適切に関連付けるには、ユーザーアカウントをリンクする 方法が必要です。 ユーザーの認証情報の悪用がかつてないほど増加している現在、ハッカーによるユーザーの本人情報の窃取が日常的に発生しており、システムを保護することは大きな課題です。その中でも特に効果的な対策の 1 つが、ユーザーが自分のアカウントを保護するための第 2 要素を設定できるようにすることです。これは一般に Multi-Factor Authentication と呼ばれます。これにより、別のアプリケーションで漏えいした username とパスワードが使用された場合でも、正当なユーザーのみが自分のアカウントにアクセスできるようになります。
ベストプラクティス 顧客向けアプリケーションでは、第 2 要素の使用をユーザーに強制 するのではなく、第 2 要素を追加する選択肢 を提供することが一般的です。詳細については、ユーザーに MFA を追加する選択肢を提供する を参照してください。 Auth0 では、ユーザーアカウントへのアクセスを保護するために MFA を有効化するための複数のオプションをサポートしています。また、柔軟な第 2 要素によるアクセス保護を実現するためのベストプラクティスもいくつかあります。
Auth0 Guardian : プッシュ通知の生成と、リクエストを許可または拒否するためのアプリケーションの両方を提供するサービスです。プッシュ通知は、事前に登録されたユーザーのデバイス (通常はスマートフォンまたはタブレット) に送信され、ユーザーはボタンを押すだけでアカウントへのアクセスを即座に許可または拒否できます。
Time-based One-Time Password (TOTP ) : Google Authenticator などのデバイスを登録し、時間経過に応じて変化するワンタイムパスワードを生成して、ユーザーアカウントを検証するための第 2 要素として入力できます。
SMS: SMS でワンタイム code を送信し、ユーザーは認証を完了する前にその code を入力するよう求められます。
Voice: 音声通話でワンタイム code を配信し、ユーザーは認証を完了する前にその code を入力するよう求められます。
Duo: Duo アカウントを多要素認証に使用できます。
Email: メールアドレスのアカウントを多要素認証に使用できます。
Guardian や Google Authenticator などのテクノロジーを使用する MFA ワークフローは、通常、モバイル端末やタブレットで動作する別個のアプリケーションを通じて提供されます。一方で、顧客に別のアプリケーションをダウンロードさせたくない場合は、Auth0 が提供する SDK を使用して、既存のモバイルアプリケーション内に第 2 要素のワークフローを直接組み込むこともできます。
推奨戦略の詳細を確認できるよう、ダウンロードして参照可能な PDF 形式の計画ガイドを提供しています。
B2B IAM プロジェクト計画ガイド 多くの B2B プラットフォームでは、顧客の組織ごとに何らかの分離やブランディングを実装しています。これは、Identity and Access Management (IAM) システムの複雑化につながる可能性があります。これに当てはまる場合は、この種の環境に関するガイダンスとベストプラクティスを確認するために、少し時間を取って目を通すことをお勧めします。
複数組織アーキテクチャ 
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム