メインコンテンツへスキップ
状況によっては、ユーザーのプロファイルに保存されている情報を変更する必要が生じます。ユーザーのプロファイル (ユーザーアカウントとも呼ばれます) は Auth0 に保存されており、その内容の変更が必要になる理由はいくつかあります。
  • セルフサービスによる情報更新
  • 組織の利用規約に関する必須更新
  • 規制遵守に伴う変更
複数の Auth0 テナントにまたがってユーザープロファイルへ直接アクセスすることはできません。本番環境で複数の Auth0 テナントを運用している場合は、この点を認識しておく必要があります。
IDプロバイダー は、ログイン処理中に提供されたデータを使用してユーザーのプロファイルを構成します。これを Normalized User Profile と呼びます。
Normalized User Profile はログイン時に IDプロバイダーの情報で更新され、その中に含まれる限られた情報は Auth0 Management API を通じて変更できます。また、Actions などの Auth0 の拡張機能を使用して、Normalized User Profile の情報を上書きすることもできます。詳しくは、User Profile Data Modification を参照してください。
デフォルトでは、各ユーザー ID ごとに 1 つのユーザープロファイルが作成されます。ここでは、いくつか検討すべき点があります。
  • ユーザー体験のカスタマイズに役立つ情報を保存する必要がある場合はどうすればよいでしょうか。
  • 由来ではないユーザー情報を保存する必要がある場合はどうでしょうか。
  • ユーザーが変更できないユーザー関連情報を保存する必要があるのはなぜでしょうか。
  • ユーザーが変更できないユーザー関連情報を保存する必要がある場合は、どうすればよいでしょうか。
  • ユーザーがパスワードを忘れた場合はどうなりますか。
  • パスワードを変更したい場合、ユーザーは何をすべきでしょうか。
  • サードパーティの組織の管理者に、自身のユーザーを管理する機能をどのように提供すればよいでしょうか。
Auth0 では、ユーザーのプロファイルにメタデータを保存できます。これにより、言語やアクセシビリティ設定などの追加情報を保持して、ユーザー体験を向上させることができます。メタデータは、ユーザーが変更できる情報と変更できない情報の両方を保存するために使用できます。後者を使うことで、たとえば既存の実装を変更することなく、ユーザープロファイルを既存システム内のレコードに関連付けることが可能になります。 パスワードを忘れたユーザーや、既存のセルフサービスの仕組み (または導入予定のセルフサービスの仕組み) を通じてパスワード変更が許可されているユーザーについては、Auth0 が提供する Password Reset 機能を利用できます。これは既存の実装に統合でき、Universal Login を含む Auth0 の標準 UI ウィジェットにもあらかじめ組み込まれています。 また、常に 検証済みのユーザーアカウント を扱うようにする必要があります。Auth0 には、そのための標準的な仕組みも用意されています。さらに、規制遵守 についても考慮する必要があります。たとえば GDPR には、EU 市民をプライバシー侵害やデータ侵害から保護するうえで、非常に具体的な要件があります。 現時点では Auth0 に標準で用意された一元的なプロファイル管理ポータルはありませんが、セルフサービスによるプロファイル管理のために、Auth0 の を使用して独自に構築したり、既存の UI を利用したりできます。Management API エンドポイントについて説明している Auth0 の コミュニティガイダンス を参照してください。Management API へのすべての呼び出しでは、アクセストークン が必要です。
セルフサービスのプロファイル管理では、セキュリティ面とデータプライバシー面の懸念が生じる可能性があります。たとえば、ユーザーによるメールアドレスの変更を許可したい場合でも、セキュリティのベストプラクティスに従わずに実施すると、ユーザーが自分のアカウントにアクセスできなくなったり、個人を特定できる情報 (PII) が漏えいしたり、さらに悪い場合にはセキュリティ侵害につながるおそれがあります。
または、 を使用して、ユーザー プロファイルの一部を管理することもできます。Auth0 Dashboard からユーザー プロファイルを管理する方法は、主に管理者向けの手段であり、本番環境でセルフサービスのプロファイル管理に使用すべきではありません。一方で、Dashboard が提供するインターフェースは、ユーザーのプロファイル情報をすばやく簡単に操作できるため、開発時には非常に便利です。 顧客の認証情報を自社システムに保存している場合に、顧客側の管理者が自分たちのユーザーを管理できるようにする必要があるなら、独自に構築することも、Auth0 Extension を使用することもできます。詳しくは Admin Portal を参照してください。

メタデータ

Normalized User Profile の情報に加えて、メタデータを Auth0 のユーザープロファイルに保存できます。メタデータを使用すると、IDプロバイダーに由来しない情報や、IDプロバイダーから提供される情報を上書きする情報を保存できます。

ベストプラクティス

メタデータの使用にあたっては、Auth0 のユーザーデータ保存のベストプラクティスに従ってください。メタデータストレージは汎用的なデータストアとして設計されていないため、可能であれば引き続き独自の外部ストレージを使用してください。メタデータのサイズと複雑さも最小限に抑える必要があります。また、Auth0 Management API には、ユーザーに関連付けられたメタデータの更新および削除に関して厳格なガイダンスがあります。
メタデータは、Auth0 Management API と Auth0 Authentication API の両方で操作できます。Normalized User Profile を管理する場合と同様に、メタデータを操作するために Management API を呼び出すには、アクセストークンが必要です。
Management API の呼び出しは、Auth0 Rate Limiting policyの対象です。この点を考慮してください。そのため Auth0 では、API を直接呼び出すのではなく、開発環境に適した Auth0 SDK を使用することを一般的に推奨しています。

ユーザーメタデータ

ユーザーメタデータ (user_metadata とも呼ばれます) は、ユーザープロファイルに保存できる情報で、ユーザーはセルフサービスによるプロファイル管理の一環としてこれを参照および更新できます。この種のメタデータには、ユーザーの敬称や、Auth0 から送信されるメールのカスタマイズに利用できるユーザーの希望言語などが含まれます。

ベストプラクティス

Auth0 のメールのカスタマイズに使用する情報は、メタデータに保存してください。ユーザーによる変更を許可する場合は、メールの言語を判定するための情報など、可能であれば user_metadata に保存することを推奨します。

アプリメタデータ

一方、アプリメタデータ (app_metadataとも呼ばれます) は、ユーザープロファイルとともに保存できる情報ですが、適切な認可がある場合にのみ読み取りまたは更新できますapp_metadataにはユーザーが直接アクセスすることはできません。この種のメタデータの例としては、ユーザーが最新の有効な利用規約に同意したことを示すフラグや、その同意日時などがあります。

パスワードリセット

パスワードを忘れたユーザーや、既存のセルフサービスの仕組みでパスワード変更が許可されているユーザー向けに、Auth0 は Password Reset 機能を提供しています。これを既存の実装に統合することも、Universal Login の一部として提供される Auth0 の標準 UI ウィジェットをそのまま利用することもできます。
パスワード変更とパスワードリセットは、Auth0 の データベース接続 タイプでのみサポートされています。
Auth0 の では、Auth0 Authentication API の機能を使用したパスワードリセット用 UX が標準で提供されています。あるいは、開発環境に適した Auth0 SDK のいずれかを通じて、Auth0 Authentication API を使用することもできます。パスワードリセットのワークフローで使用されるメールテンプレートは、Auth0 の標準 UI ウィジェットを使用する場合でも、カスタマイズした Universal Login を使用する場合でも、完全にカスタマイズできます。 一方、Auth0 Management API を使用すると、データベース接続 タイプで定義されたユーザーアイデンティティのパスワードを直接変更できます。Auth0 Management API は、セルフサービスのプロファイル管理実装の一部として使用できるほか、パスワード変更ページのカスタマイズの一部として使用することもできます。

アカウントの確認

また、常に確認済みのユーザーアカウントを使用し、Auth0 が提供する仕組みを活用する必要があります。さらに、GDPR のような規制遵守についても考慮してください。GDPR には、EU 市民をプライバシー侵害やデータ漏えいから保護するための非常に具体的な要件があります。 Auth0 には、ユーザーのメールアドレスに 確認メール を送信してアカウントを確認するための標準機能が用意されています。デフォルトでは、Auth0 は セルフサインアップ の一環として作成された データベース接続 の ID に対して、確認メールを自動的に送信します。ただし Auth0 では、ユーザー登録時に Social Provider によるメールアドレスの検証が行われない場合に確認メールを送信できる Management API エンドポイント も提供しています。

ユーザーのブロック

Auth0 のユーザーアクセスのブロックでは、特定の条件下でユーザーがアプリケーションにログインできないようにできます。デフォルトでは、Auth0 Dashboard に、管理者がすべてのアプリケーションに対するユーザーアクセスをブロックおよびブロック解除できる標準の仕組みが用意されています。また、この機能は Auth0 Management API を使用して実装することもできます。さらに、Auth0 の拡張機能を利用して、特定のアプリケーションに対するユーザーアクセスを無効化したり、よりきめ細かなアクセス制御を提供したりすることもできます。 さらに、Auth0 Management API では、誤った認証情報が過剰に使用されたために無効化されたユーザーのブロックを解除することもできます。

管理者ポータル

管理者ポータルは、新規ユーザーの作成、ユーザーのプロファイル編集、ユーザーのアクティビティ確認などを行えるアプリケーションです。このアプリケーションには、管理者のみがアクセスできるようにする必要があります。Auth0 には管理ダッシュボードが用意されていますが、誤って Auth0 テナントに問題を起こしかねない操作が数多くあるため、多くの人に管理ダッシュボードへのアクセスを付与することは推奨されません。代わりに、Auth0 では次の 2 つの選択肢を提供しています。
  • Auth0 Management API: Management API を使用すると、管理者がユーザーを管理できるアプリケーションを簡単に構築できます。これは、管理者向けにすでに利用している既存のアプリケーションに組み込むことも、現在のアプリケーションに合わせた UI を備えた新しいアプリケーションとして作成することもできます。
  • Auth0 Delegated Administration Extension: この強力で柔軟な拡張機能を使用すると、ユーザー管理エクスペリエンスをカスタマイズできます。この拡張機能を調整することで、顧客側の管理者がログインできるようにしつつ、自分の組織内のユーザーのみを表示および管理できるようにできます。

ベストプラクティス

管理者がユーザーを管理する独自の方法を提供する場合は、管理者がパスワードを直接設定できるようにするのではなく、メールでパスワード変更リンクをユーザーに送信することだけを許可するべきです。どうしてもこの推奨に従えず、管理者が他者のパスワードを設定できるようにする必要がある場合は、本人だけがパスワードを知る状態にするため (管理者も把握しないようにするため) 、次回ログイン時にユーザーへパスワードの変更を強制するべきです。

プロジェクト計画ガイド

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

複数組織アーキテクチャ (マルチテナンシー)

多くの B2B プラットフォームでは、顧客の組織ごとに何らかの分離やブランディングを実装しています。そのため、Identity and Access Management (IAM) システムが複雑になることがあります。これに該当する場合は、このような環境に関するガイダンスとベストプラクティスに目を通すことをお勧めします。 複数組織アーキテクチャ