- セルフサービスでの情報更新
- 組織の利用規約に関わる義務的な更新
- 規制順守に伴う変更
複数のAuth0テナントにまたがるユーザープロファイルには、直接アクセスすることはできません。運用環境に複数のAuth0テナントをデプロイする場合は、注意が必要です。
正規化ユーザープロファイルは、ログイン時にIDプロバイダーによって更新されるため、Auth0 Management APIを使って変更できるプロファイル情報は限られます。正規化ユーザープロファイルの情報をオーバライドする別の方法として、Rulesなど、Auth0の拡張機能を利用することもできます。詳細については、「ユーザプロファイルのデータを編集する」を参照してください。
- ユーザーエクスペリエンスのカスタマイズに役立つように情報を保管するにはどうすれば良いのか。
- 発生源がIDプロバイダーではないユーザー情報を保管しなければならない場合にはどうすれば良いのか。
- ユーザーが自分で変更できないユーザー関連情報を保管しなければならない理由は何か。
- ユーザーが自分で変更できないユーザー関連情報を保管しなければならない場合にはどうすれば良いのか。
- ユーザーがパスワードを忘れた場合にはどうなるのか。
- ユーザーが自分のパスワードを変更したい場合、ユーザーはどうすれば良いのか。
セルフサービスのプロファイル管理では、セキュリティ・データプライバシー上の懸念が生じる可能性があります。たとえば、ユーザーに対してメールアドレスの変更を許可したい場合に、セキュリティガイダンスに従わずにそれを行うと、ユーザーがアカウントからロックアウトされたり、個人を特定できる情報（PII）が漏洩したり、最悪の場合にはセキュリティ侵害が生じたりします。
メタデータ
Auth0のユーザープロファイルには、正規化ユーザープロファイルの情報以外に、メタデータも保管することができます。メタデータは、発生源がIDプロバイダーではない情報や、IDプロバイダーが提供する情報をオーバーライドするような情報を保管できるようにします。ベストプラクティス
メタデータを使用するには、Auth0「ユーザーデータ保存のベストプラクティス」に従ってください。メタデータの保存は汎用のデータストアとして設計されておらず、可能な限り独自の外部ストレージ施設を使用するべきです。メタデータのサイズと複雑さは最小に保たれるべきで、Auth0 Management APIにはユーザーに関連するメタデータの更新および/または削除についての厳格な一連のガイダンスがあります。Management APIへの呼び出しにはAuth0レート制限ポリシーが適用されることを考慮してください。Auth0は、通常、APIを直接呼び出す代わりに、開発環境に適したAuth0 SDKを使用することを推奨しています。
ユーザーメタデータ
ユーザーメタデータ（またはuser_metadata）は、ユーザープロファイルに対照して保管できる情報であり、セルフサービスのプロファイル管理の一環としてユーザーが読み取りや更新を行える情報です。この種のメタデータには、ユーザーの敬称や使用する言語などが含まれ、Auth0から送信するメールをカスタマイズするのに使うことができます。
ベストプラクティス
Auth0のメールをカスタマイズするために使用する情報は、メタデータに保存し、ユーザーが変更できる場合（メールの言語を決定するために使用される情報など）は可能な限りuser_metadataに保存しましょう。アプリメタデータ
アプリメタデータ（またはapp_metadata）は、ユーザープロファイルと一緒に保管できる情報ですが、適切な許可がある場合のみ読み取りや更新 が行えます。ユーザーはapp_metadataには直接アクセスできません。この種のメタデータには、ユーザーが最後に承認した有効な利用規約のセットを示すフラグや、いつ承認したかを示す日時などが含まれます。
パスワードのリセット
自分のパスワードを忘れてしまったユーザーや、すでにある何らかのセルフサービスの仕組みを使ってパスワードを変更できるユーザーについては、Auth0が提供しているパスワードのリセット機能を活用できます。これは、既存の実装と統合できるだけでなく、ユニバーサルログインの一部として、そのままで便利に使えるAuth0のUIウィジェットにすでに組み込まれています。パスワード変更とパスワードリセットは、Auth0データベース接続タイプでのみサポートされています。
アカウント検証
扱っているのが常に検証済みのユーザーアカウントであることを確認し、Auth0が提供している仕組みを活用する必要があります。規制を順守するために、プライバシーやデータの侵害からEU市民を保護する目的で詳細な要件を定めたEU一般データ保護規則（GDPR）なども考慮しなければなりません。 Auth0は、ユーザーのメールアドレスに確認メールを送信してアカウントを検証できるように、そのままで使える機能を提供しています。データベース接続のIDがセルフサインアップによって作成されたものである場合、Auth0はデフォルトで自動的に確認メールを送信します。ただし、Auth0はManagement APIエンドポイントも提供して、ユーザーの登録時にソーシャルプロバイダーがメール検証を行わない場合、確認メールの送信に使えるようにしています。ユーザーをブロックする
Auth0でユーザーのアクセスをブロックすると、特定の条件下でユーザーがアプリケーションにログインするのを防ぐことができます。すべてのアプリケーションに対して、管理者がユーザーのアクセスをブロックまたはブロック解除できるように、Auth0 Dashboardはデフォルトでそのまま使える仕組みを提供しています。この機能性は、Auth0 Management APIを使って実装することができます。また、Auth0の拡張性を利用して、特定のアプリケーションに対してユーザーのアクセスを無効化したり、さらにきめの細かいアクセス制御を提供したりもできます。 また、誤った資格情報を複数回使用したため無効になってしまったユーザーをブロック解除するのに、Auth0 Management APIを使うこともできます。ユーザーアカウントをリンクする
デフォルトでは、各ユーザーIDに対して1つのユーザープロファイル（ユーザーアカウント）があります。FacebookやGoogleのソーシャル認証、Auth0のユーザー名とパスワードの認証など、複数のIDプロバイダーからのログインを有効にしている場合には、それぞれに別途のユーザープロファイルがあります。Auth0のユーザーアカウントをリンクする機能は、関連する各種のIDの総体として、1人のユーザーについて1つのプロファイルを作成できるようにします。 アカウントをリンクする処理では、2つのユーザープロファイルが結合されます。リンクを処理する際には、メインアカウントとサブアカウントが指定されなければなりません。ただし、リンク可能なアカウントの数は1組以上でも構いません。たとえば、すでに複数のアカウントが結合されているアカウントをメインアカウントとして、別のサブアカウントをそれにリンクさせることができます。つまり、1つのユーザーアカウントに複数のIDが関連付けられることになり、これには以下の利点があります。- ユーザーが複数のIDを使ってログインできるようになり、それぞれに別途のプロファイルを作成する必要はありません。
- 登録済みユーザーは新しいログインIDを使用できると同時に、既存のプロファイルを使い続けることができます。
- ユーザーは、どのIDをログインに使っても、自分の同じプロファイルを維持することができます。
- ユーザーは、より完全なプロファイルを提供するために、身元情報が多いアカウントにリンクさせることができます。
- アプリケーションは、接続固有のユーザープロファイルデータを取得できます。
プロビジョニング解除
アプリケーションは、ユーザーによるアカウント削除の要求に対応しなければならないことがあります（たとえば、GDPRを遵守するためなど）。そのような機能は、他のプロファイル関連の機能と一緒に、Management APIを使って実装することができます。Management APIを使用すると、ユーザーについて保管されている情報を取得したり、必要に応じて更新したりできます。 Auth0には、サインアップ時に同意通知やデータ保護へのリンクを表示して、ユーザーが自分についてのデータを閲覧・修正する権利を尊重するなど、プライバシーに関連した各種要件に対応する機能があります。GDPRや他のプライバシーに関する指令では、自分に関するデータを閲覧して訂正できるユーザーの権利が要求されています。また、ユーザーには「忘れられる」権利も認められています。Management APIを使用してこれらの要件に対応し、法的義務を果たすことができます。