ユーザープロファイル

テナントのアプリにアクセスするには、ユーザーはテナントにプロファイルがなくてはなりません。ユーザープロファイルには、名前や連絡先など、ユーザーについての情報が含まれます。ユーザープロファイルは、Auth0 DashboardとAuth0 Management APIで管理できます。

ユーザーデータは、独自のデータベースの他にも、ソーシャル、法務、エンタープライズIDプロバイダーなど、多数のソースから取得する可能性があります。例としては、Google、Facebook、Active Directory、SAMLなどが挙げられます。対応しているデータソースからのユーザーデータは、正規化することができます。

ユーザープロファイル属性には、IDプロバイダーからの情報を含むことができます。たとえば：

Auth0は、ユーザーデータソースに接続してユーザーを認証するため、すべてのユーザーデータソースを接続と呼びます。

Auth0はさまざまなIDプロバイダーとデータベース接続に対応します。それぞれの接続は、異なるユーザー属性を返すことができます。場合によっては、接続間で同じ属性に異なる名前が使われることもあります。たとえば、ある接続でsurname（姓）と呼ばれるものが、別のデータソースではlast_nameやfamily_nameと呼ばれる場合があります。

こうした複雑性に対処するため、Auth0では、ユーザーデータを保存する際、Auth0固有の正規化ユーザープロファイルを提供しています。

Auth0のAD/LDAPコネクターを使用するActive Directoryや他のLDAP接続のために、ディクレトリサービスにあるユーザープロファイル属性を、Auth0の正規化されたユーザープロファイルにマッピングする機能があります。AD/LDAPコネクターのインストールディレクトにあるprofileMapper.jsファイルは、ユーザーの認証時に属性をマッピングします。

アプリケーションがAuth0との通信にSAMLプロトコルを使用する場合、2つの仕組みのいずれかが、ユーザー属性をAuth0の正規化されたユーザープロファイルに一致させます。

ユーザーは、まず1つの接続（カスタムデータベースなど）でアプリケーションにログインした後に、別の接続（Facebookなど）でログインすることができます。この場合、2回目の認証のuser_idは、最初の認証で使われたuser_idとは異なります。

Auth0には、この2つのアカウントをリンクする機能があります。Auth0は2つのアカウントをリンクする場合、ユーザープロファイルのidentities配列部分に、各接続に対して1つずつ、2つの要素を保存します。

Auth0が複数のプロバイダーからのユーザープロファイル属性をマージすることはありません。Auth0は、最初に使われたプロバイダーのcoreユーザープロファイル属性を使用します。

詳細については、「ユーザーアカウントのリンク」をお読みください。

Auth0は、接続から受け取ったユーザープロファイルをキャッシュしてから、アプリケーションに渡します。このキャッシュはAuth0のデータベースにあります。ユーザーが認証する度に、Auth0はキャッシュを更新します。詳細については、「データベースでユーザープロファイルを更新する」をお読みください。

Auth0では、IDプロバイダーからのものではない各ユーザーの関連データであるメタデータを保存できます。ユーザーの好きな色や趣味など、カスタム属性を保存するためにuser_metadataを使えます。

ユーザープロファイル情報を変更するには、いくつかの方法があります。

• スコープ：Auth0が対応する認証フローには、スコープを指定するオプションパラメーターがあります。これは、IDトークン（JWT）に含まれるユーザープロファイル情報（クレーム）を制御します。

• Auth0 Dashboard：Dashboardでは、どのユーザープロファイルでも、user_metadataとapp_metadata部分を手動で編集できます。

• Management API：Auth0のデータベースに保管されたユーザープロファイルの読み取り、更新、削除を行うことができます。

• カスタムデータベースのスクリプト：カスタムデータベース接続を使用している場合には、スクリプトを作成して、パスワードの作成、ログイン、検証、削除、変更など、ライフサイクルイベントを実装することができます。Auth0はスクリプトのテンプレートを提供しています。特定のデータベースまたはスキーマに合わせて、このスクリプトを書き換えることができます。

• ルール：ルールを使用すると、認証のトランザクション中にユーザープロファイルを拡張し、オプションでそれらをAuth0に書き戻すことができます。

ユーザーのプロファイル情報には、アプリとAuth0 Management APIからアクセスすることができます。

Auth0が認証を完了すると、アプリケーションに制御を戻す際に、ユーザープロファイルを提供します。具体的なレベルでは、Auth0が対応するアプリケーションプロトコルのいずれかを使ってこれを実行できます。ただし、ほとんどの場合、開発者にはAuth0 SDKの使用が好まれるはずです。詳しくは、Quickstartをお読みください。

SDKの1つに、ユーザーログインのインターフェイスを提供する、Auth0 Lockウィジェットがあります。詳細については、以下をお読みください。

• Web用のLock

• Lock Swift

• Lock.Android

WebアプリにカスタムのログインUIを実装したい場合には、Auth0.jsを使用することができます。このAuth0用のヘッドレスなJavaScriptライブラリーは、認証フロー（と他のタスク）を起動して、その見返りにユーザープロファイルオブジェクトを受け取ります。詳細については、「Auth0.js v9の参考情報」をお読みください。

Auth0はREST APIを提供して、アプリケーションとサービスがユーザープロファイルオブジェクトにアクセスして操作できるようにしています。

API Explorerを使用すると、対話的にManagement APIを試すことができます。以下を提供しています。

• 利用可能なAPIの呼び出し

• それぞれの呼び出しに必要な情報

• それぞれの呼び出しで戻される情報

Explorerを使用すると、各エンドポイントをExplorer UIで試したり、各コマンドラインからCuRLを使用して試したりできます。Management APIコマンドを試すには、API Explorerにアクセスします。update:usersなど、選択するコマンド内の［Scopes（スコープ）］から必要なアクセスを選択し、［TRY（試す）］をクリックします。

Auth0 Authentication APIは、認証フロー専用です。詳細については、「Authentication API Explorer」をお読みください。これらほとんどのエンドポントは、さまざまなAuth0 SDKで使用されていますが、コードで典型的に使用されるようなものではありません。

上記の認証フローでは、Auth0は完全なユーザープロファイルの代わりにトークンのセットを返します。

返されるトークンの1つに、IDトークンがあります。これはJSON Web Token（JWT）で、ユーザープロファイル属性がクレームの形で含まれています。これらのクレームはユーザーについてのステートメントです。クレームは、トークンの消費者がその署名を検証できた場合には信頼できます。この署名は（HS256の場合）、Auth0アプリのクライアントシークレットを使用して生成されます。アプリがRS256暗号を使用している場合には、IDトークンは秘密鍵で署名され、公開鍵で検証されます。アプリはJWTを解読して、ペイロードにあるユーザー情報を取得することができます。この情報には、ユーザー名、メール、その他の通常ユーザーエクスペリエンスの一部となるデータなどが挙げられます。

一般的に、JWTのクレームには、ユーザープロファイルにある情報のサブセットのみが含まれています。そうすることで、トークンのサイズが最小限に抑えられます。詳細については、「JSON Webトークン」をお読みください。

認証中には、他にも3種類のトークンが返されます。

• Auth0のアクセストークン

• サードパーティプロバイダーのアクセストークン

• リフレッシュトークン

トークンとクレームの詳細については、「トークン」をお読みください。

• ユーザープロファイルの確認
• カスタムドメインのトラブルシューティング
• SAMLエラーのトラブルシューティング
• 接続を確認する
• APIの呼び出しをチェックする
• Auth0.Androidのログイン、ログアウト、およびユーザープロファイル