認証 (B2C)

B2C IAM 実装における認証の仕組み。

ユーザーにサービスを提供するには、そのユーザーが誰であるかを識別できなければなりません。このプロセスはユーザー認証と呼ばれます。ユーザーを認証する方法には、ソーシャルメディアアカウント、ユーザー名とパスワード、パスワードレスなど、さまざまなものがあります。また、ユーザー認証では、第1要素だけに頼らず、多要素認証 (MFA) を有効にすることが推奨される場合も少なくありません。

​

ベストプラクティス

ユーザーの認証方法を設計する際は、セキュリティとユーザー体験の両方を考慮することが重要です。複数の第1要素を用意したり、認証時に複数の要素を必須にしたりすることで、その両方を実現できます。

機能やワークフローを検討する際には、考慮すべき点が数多くあります。

• ユーザーはどこで認証情報を入力しますか。
• ユーザーの認証情報をどのように安全に保ちますか。
• 認証システムをどのように維持しますか。
• ユーザーにパスワード認証をどのように提供しますか。
• 攻撃者がユーザーになりすましてログインしようとするのを、どのように防ぎますか。
• 異なる種類のアプリケーションで認証をどのように実装しますか。
• 異なる言語背景を持つユーザーに対して、ログインをどのように簡単にしますか。
• レガシー認証システムから移行する際に、優れたユーザー体験をどのように提供しますか。
• アプリケーションを Auth0 と統合する際には、何を考慮すべきですか。
• ユーザーは既存のソーシャルアカウント (たとえば Facebook や Google) を使ってログインできますか。
• 多要素認証を提供する必要がありますか。
• ユーザーが事前にログインする手段を持たないサービスがある場合、どうしますか。
• ある API の同じユーザーのアクセストークンを、別の API に渡せますか。

Auth0 のUniversal Loginは、ユーザー ID／パスワード認証情報によるサインインを提供する場合でも、Social Loginによる、いわゆる Bring Your Own Identity のシナリオを許可する場合でも、ユーザーに安全で安心な体験を提供します。さらに、製品固有のbranding要件がある場合でも、Universal Loginでログイン体験を一元化することには、ブランド認知の面での利点もあります。Universal Login で通常使用される Auth0 の UI ウィジェットは、異なる言語要件を持つユーザー向けのinternationalizationを標準でサポートしています。また、MFAや攻撃対策といった Auth0 の機能も標準でサポートしているため、攻撃者がユーザーアカウントにアクセスしようとするのを防ぐための対策を講じることができます。

ユーザー ID／パスワード認証情報によるサインインを許可すると、ユーザーがシステムにアクセスする際に、サードパーティーのID プロバイダーの状態に依存せずに済みます。また、使用する認証情報を自社のポリシーに沿ったものにすることもできます。Auth0 は、ユーザー ID／パスワードによるログインを支援する複数の選択肢を提供しており、guidance providedを読むことで、これらの選択肢をどのように活用できるかを理解できます。さらに、追加の第1認証要素として、どこかの段階でsocialサポートを加えると、柔軟性が高まるだけでなく、さまざまなソーシャルログインのprovidersがすでに保持している情報を活用することで、追加で質問しなくてもユーザー理解を深めるのに役立ちます。

既存のレガシーなアイデンティティストアがある場合は、User Migrationもご覧ください。このセクションでは、安全性とセキュリティの観点から、Auth0 のマネージドアイデンティティストレージに移行するメリットを説明しています。

顧客向けアプリケーションでは、OpenID Connect (OIDC) が最も広く使われている業界標準のプロトコルであり、Auth0 は OIDC をネイティブにサポートしています。Auth0 は、さまざまなアプリケーションを統合するための多様なアプローチをサポートしているため、適切な選択を行うために必要な情報については、アプリケーション統合のセクションをご覧ください。

ある API から別の API を呼び出す場合や、認証済みユーザーのコンテキストが存在しない状況、たとえば 1 つ以上の cron ジョブ、レポート生成ツール、または継続的インテグレーション／デリバリーシステムなどでは、userではなくapplicationを認可する方法が必要になります。これは 1 段階のプロセスで、アプリケーションを認証し (client ID とシークレットを使用) 、その後 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. Authorization Server からのレスポンスを受け取り処理するようにアプリケーションを設定します。

​

ユーザー名とパスワードによる認証

ほぼすべての B2C アプリケーションでは、顧客が新しい認証情報を作成できるようになっています。これは、ほとんどのユーザーにとってなじみのある一般的な認証方式です。

Auth0 では、ユーザー名とパスワードによる認証に複数の方式があります。既存のユーザー基盤を持たない新規開発のアプリケーションであれば、Auth0 の標準機能であるシンプルな Database Connection だけで、ユーザー認証を始めるために必要なものがすべて揃います。一方、独自のユーザーデータベースや既存の LDAP システムなど、レガシーなユーザーストアがある場合は、User migration に関するガイダンスで説明しているとおり、ユーザーを移行するためのいくつかの選択肢があります。

データベース接続にどのようにユーザーを登録する場合でも、それらのユーザーの認証方法はほぼ同じです。ユーザーに、ユーザー名とパスワードを入力するフォームを表示する必要があります。Universal Login に関するガイダンスでも述べたとおり、ユーザー名とパスワードでユーザーを認証する最も簡単かつ安全な方法は、ユーザーを一元化されたログインページにリダイレクトし、そこでユーザー名とパスワードを入力してもらうことです。これにより Auth0 は、ユーザーがすでに認証済みかどうかを判断し、不要な場合はログインフォーム自体を表示せずに済みます。

​

ベストプラクティス

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

​

アプリケーション統合

ユーザーをどのように認証するかが決まったら、次はその認証をどのように開始するかを決めます。通常、アプリケーションごとに認証の開始地点は異なります。

ネイティブモバイルアプリケーション (およびデスクトップアプリケーション) では、認証にシステムブラウザーを使用する必要があります。そうしないと、セキュリティリスクが増大するおそれがあります。詳しくは Native Login を参照してください。

前述のとおり、顧客向けアプリケーションでは、多くのお客様が業界標準のプロトコルとして OpenID Connect (OIDC) を使用しています。まず最初に行うべきことは、どの OIDCフロー を使うかを決めることです。そのため、まずは 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 のような認可サーバーへのリダイレクトに対応したミドルウェアをサポートしています。選定する際は、次の重要な点を考慮してください。

• コンフィデンシャルクライアント、非コンフィデンシャルクライアント、またはその両方への対応
• ディスカバリーエンドポイント 経由の設定、または明示的なインライン設定への対応
• 有効期限、署名、クレーム、スコープを含むトークン検証への対応
• 必要に応じた リフレッシュトークン への対応

​

ユーザーの認証

認証とは、ユーザーの本人確認を行うプロセスです。OIDCにおける認証の結果は、ID Tokenです。このトークンにはユーザーに関する情報が含まれており、認可サーバーで定義された1つ以上の要素を使ってユーザーが認証した場合にのみ取得できるようにする必要があります (最も一般的なのは、ユーザーIDとパスワードです) 。ID Token の取得に加えて、以下の点も考慮する必要がある場合があります。

• 共有APIを呼び出すために、アクセストークン も必要ですか？
• アプリケーションはシングルページアプリケーションで、必要なのは ID Token だけですか？ 詳しくは Authorization Code Grant with PKCE を参照してください。
• アプリケーションはネイティブアプリケーション (モバイルまたはデスクトップ) ですか？ また、リフレッシュトークン は必要ですか？ 詳しくは Authorization Code Grant with PKCE を参照してください。

本番環境に移行する前に、各アプリケーションについて、使用しているグラント のみ が アプリケーションの設定 で有効になっていることを確認してください。

​

認可コードグラント (PKCE あり／なし)

お使いの SDK が Authorization Code grant のみをサポートしている場合や、アクセストークン または リフレッシュトークン が必要な場合は、Authorization Code grant (PKCE のあり／なし) を使って ID Token を取得することもできます。Authorization Code grant では、コードをトークンに交換するために追加の API 呼び出しが必要になるため、ID Token だけが必要な場合には、不必要なレイテンシが発生することがあります。多くの場合、ID Token への最適なアクセスを確保しつつ、アクセストークン と リフレッシュトークン を安全に取得するために Authorization Code grant のワークフローも活用できるよう、ハイブリッドフロー が実装されます。

Auth0 は、ID Token のみを必要とするブラウザベースのアプリケーションでの implicit grant の利用をサポートしていますが、PKCE を使用する authorization code grant の利用を推奨しています。詳しくは、Auth0 Blog の OAuth2 Implicit Grant and SPA を参照してください。

ユーザーを再認証させることなく新しい アクセストークン または ID Token を取得できるようにするために リフレッシュトークン が必要な場合は、authorization code grant を使用する必要があります。

​

攻撃対策

認証システムが重要なのは、悪意のある者が、本来アクセス権のないアプリケーションやユーザーデータにアクセスするのを防ぐためです。こうした悪意のある者が自社システムにアクセスできないよう、できるだけ多くの防御策を講じる必要があります。その最も簡単な方法の 1 つが、Auth0 の攻撃対策が正しく設定されていることを確認することです。このトピックに関するガイダンスをぜひ一読し、適切に機能していることを確認してください。

​

ベストプラクティス

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

​

レガシーシステムとの SSO

大規模な再構築では、すべてのアプリケーションを一度に更新することが、常に可能であるとは限らず、現実的でもありません。実際、Auth0 との統合にあたっては、段階的に進めるアプローチを前提に計画することをベストプラクティスとして推奨しています。アプリケーションがすでにシングルサインオン (SSO) に対応しており、レガシーのアイデンティティシステムが OIDC や SAML のようなプロトコルをサポートしている場合は、Auth0 との統合を進めながら引き続き SSO を提供するために、いくつかの選択肢があります。

• レガシー SSO システム内の既存の ID プロバイダーを更新し、ログイン時に Auth0 にリダイレクトする (例: SAML を使用) 、または
• Auth0 からレガシー SSO システムにリダイレクトしてログインさせる。この場合、Auth0 でレガシーシステムを IdP として設定する必要があります (つまり、SAML または OIDC を使用します) 。

​

ベストプラクティス

レガシーシステムでの SSO エクスペリエンスをサポートすると複雑さは増しますが、Auth0 との統合を進める中で、よりシームレスなユーザー体験を実現するうえで、その価値がある場合があります。この方法を採る予定であれば、早い段階で計画しておくことで、実現可能性を確保しやすくなります。まだ中央集約型のサービスで SSO を提供していない場合は、それを追加する複雑さは、得られるメリットに見合わない可能性が高いでしょう。

これは複雑なトピックであり、現在のレガシーアーキテクチャによっては追加の調査が必要になる可能性が高いため、現時点でレガシーシステムが SSO をサポートしている場合にのみ検討することをお勧めします。注: 現在、アプリケーションから中央集約型のシステムにリダイレクトしてユーザーを認証しており、そのシステムが、その中央集約型システムとのセッションがまだない場合にのみ認証情報を求めるのであれば、それはレガシー SSO の実装です。

​

ソーシャル認証

Facebook や Google などが提供する「自身の ID を持ち込む」シナリオは、セキュリティを損なうことなくユーザー認証の体験をシンプルにできる有効な方法です。Universal Login を使用すれば、Social Connections のサポートも最小限の手間で簡単に追加し始められます。

Auth0 では、事前構成済みの開発者キー を使ってソーシャル接続を簡単にテストできます。ただし、これらには制限事項があるため、本番環境に移行する前に、選択したソーシャルプロバイダーごとの手順に従って、アプリケーション専用のキーを設定する必要があります。

social をサポートすると、ユーザーの ID と認証情報はソーシャルプロバイダーによって管理され、一部の ID クレームも同様に管理されます。Auth0 はそれらを使ってユーザーのプロフィールを作成します。さらに Auth0 は、Social Identity Providers (Social IdPs) のアクセストークンも提供できるため、アプリケーションはユーザーに代わってサードパーティの Social IdP API を呼び出すこともできます。

​

ベストプラクティス

ソーシャル認証は便利な機能ですが、サインイン方法を複数提供する場合は、顧客が実際に複数の方法を使ってサインインする可能性を考慮する必要があります。既定では、Auth0 では各ユーザー ID ごとに個別のユーザープロフィールが作成されるため、1 つのユーザープロフィールに複数の ID を関連付ける効果的な方法として、Auth0 のユーザーアカウントのリンク機能の利用を検討するとよいでしょう。

Auth0 の Custom Social Connections extension を使うと、標準ではサポートされていない OpenID Connect (OIDC) 準拠の任意のサードパーティベンダーにも接続でき、ソーシャル認証をさらに拡張できます。たとえば、政府発行 ID のプロバイダーである SwissID も、Custom Social Connection を使用して Auth0 で構成できます。

​

多要素認証 (MFA)

ユーザー認証情報の悪用がかつてないほど増えている現在、ハッカーによる個人情報の窃取が日常的に発生しているなかで、システムを保護することは大きな課題です。しかし、その対策として特に効果的なのが、アカウント保護のための第 2 要素をユーザー自身で設定できるようにすることです。これは一般に Multi-Factor Authentication と呼ばれます。これにより、たとえ別のアプリケーションから漏えいしたユーザー名とパスワードが使われた場合でも、正当なユーザー本人だけが自分のアカウントにアクセスできるようになります。

​

ベストプラクティス

顧客向けアプリケーションでは、第 2 要素の利用を強制するのではなく、追加できる選択肢としてユーザーに提供するのが一般的です。詳しくは、ユーザーに MFA を追加する選択肢を提供する を参照してください。

Auth0 は、ユーザーアカウントへのアクセスを保護するために MFA を有効にする複数の方法をサポートしており、さらに、柔軟な第 2 要素による保護を確実に提供するためのベストプラクティスもいくつかあります。

• Auth0 Guardian: プッシュ通知の送信機能と、リクエストを許可または拒否するためのアプリケーションを提供するサービスです。プッシュ通知は、ユーザーが事前登録したデバイス (通常はスマートフォンやタブレット) に送信され、ユーザーはボタンを押すだけでアカウントへのアクセスをすぐに許可または拒否できます。
• Time-based One-Time Password (TOTP): Google Authenticator などのデバイスを登録すると、時間とともに変化するワンタイムパスワードが生成され、それを第 2 要素として入力してユーザーアカウントを検証できます。
• SMS: SMS でワンタイムコードを送信し、認証を完了する前にユーザーにその入力を求めます。
• Voice: 電話でワンタイムコードを伝え、認証を完了する前にユーザーにその入力を求めます。
• Duo: 多要素認証に Duo アカウントを使用できます。
• Email: 多要素認証にメールアカウントを使用できます。

Guardian や Google Authenticator などを使った MFA のワークフローは、通常、スマートフォンやタブレットで動作する別個のアプリケーションを通じて提供されますが、顧客に別のアプリケーションをダウンロードさせたくない場合に備えて、Auth0 は既存のモバイルアプリケーション内に第 2 要素のワークフローを組み込むために使用できる SDK も提供しています。

​

プロジェクト計画ガイド

推奨戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドをご用意しています。

B2C IAM プロジェクト計画ガイド