Authenticate
Manage Users
Customize
Platformユーザーデータソース
ユーザーデータは、自社のデータベースをはじめ、ソーシャル、法的機関、エンタープライズの各など、さまざまなソースから取得できます。たとえば、Google、Facebook、Active Directory、 などがあります。サポート対象の任意のデータソースから取得したユーザーデータは正規化できます。 ユーザープロファイルの属性には、アイデンティティプロバイダーからの情報を含めることができます。以下はその例です。
Auth0 では、ユーザーを認証するためにそれらに接続することから、すべてのユーザーデータソースを 接続 と呼びます。
Auth0 に保存させたくないユーザー属性がある場合は、ユーザー属性を DenyList に追加できます。
ユーザーデータの正規化
Auth0 は、さまざまな アイデンティティプロバイダー と データベース接続 をサポートしています。接続ごとに返されるユーザー属性は異なる場合があります。また、同じ属性でも接続によって名前が異なることがあります。たとえば、ある接続ではsurname という属性が、別のユーザーデータソースでは last_name や family_name になっている場合があります。
こうした複雑さに対応するため、Auth0 では、ユーザーデータを保存するための Auth0 独自の標準として 正規化されたユーザープロファイル を提供しています。
Auth0 の ユーザープロファイルのデータ構造 を確認するには、Auth0 Dashboard > User Management > Users に移動し、ユーザーをクリックします。
ユーザープロファイル属性マッピング
AD/LDAP Connector
Auth0 AD/LDAP Connector を使用する Active Directory やその他の LDAP 接続では、ディレクトリサービス内のユーザープロファイル属性を Auth0 の正規化されたユーザープロファイルにマッピングする仕組みが用意されています。AD/LDAP Connector のインストールディレクトリにあるprofileMapper.js ファイルによって、ユーザーの認証時に属性がマッピングされます。
SAML アサーション
アプリケーションが Auth0 との通信に SAML プロトコルを使用している場合、ユーザー属性を Auth0 の正規化されたユーザープロファイルにマッピングする方法は 2 つあります。アカウントのリンク
ユーザーは、最初は 1 つの接続 (カスタムデータベースなど) を使用してアプリケーションにログインし、その後、別の接続 (Facebook など) を使用してログインできます。この場合、2 回目の認証のuser_id は、1 回目の認証の user_id とは異なります。
Auth0 には、この 2 つのアカウントをリンクする仕組みがあります。Auth0 がこの 2 つのアカウントをリンクすると、ユーザープロファイルの identities 配列部分に、各接続に対応する要素が 1 つずつ、合計 2 つ保存されます。
Auth0 は、複数のプロバイダーからのユーザープロファイル属性を統合しません。Auth0 は、最初に使用されたプロバイダーから core ユーザープロファイル属性を取得します。
詳しくは、ユーザーアカウントのリンクを参照してください。
ユーザープロファイルのキャッシュ
Auth0 は、接続から受け取ったユーザープロファイルを呼び出し元のアプリケーションに渡す前にキャッシュします。このキャッシュは Auth0 のデータベースに保存されます。ユーザーが認証されるたびに、Auth0 はこのキャッシュを更新します。詳しくは、データベースを使用してユーザープロファイルを更新する をお読みください。カスタムユーザープロファイルデータ
Auth0 では、メタデータを保存できます。これは、各ユーザーに関連付けられた、アイデンティティプロバイダーから取得したものではないデータです。user_metadata を使用すると、ユーザーの好きな色や趣味などのカスタム属性を保存できます。
ユーザープロファイルデータを変更する
ユーザーのプロファイル情報は、いくつかの方法で変更できます。- スコープ: Auth0 がサポートする認証フローには、スコープを指定できるオプションのパラメータがあります。これにより、 () に含まれるユーザープロファイル情報 (クレーム) を制御できます。
- Auth0 Dashboard: Auth0 Dashboard では、任意のユーザーのプロファイル内にある
user_metadataとapp_metadataを手動で編集できます。 - Management API: Management API を使用すると、Auth0 データベースに保存されているユーザープロファイルの読み取り、更新、削除を行えます。
- カスタムデータベーススクリプト: 接続としてカスタムデータベースを使用している場合は、create、login、verify、delete、change password などのライフサイクルイベントを実装するスクリプトを記述できます。Auth0 では、特定のデータベースやスキーマに合わせて変更できる、これらのスクリプト用テンプレートを提供しています。
- ルール: 認証トランザクション中にルールを使用してユーザープロファイルを拡張し、必要に応じてその変更を Auth0 に永続化できます。
ユーザープロファイルへのアクセス
アプリと Auth0 の の両方から、ユーザーのプロファイル情報にアクセスできます。アプリからユーザープロファイルにアクセスする
Auth0 で認証が完了して制御がアプリケーションに戻ると、ユーザープロファイルがアプリケーションに渡されます。より低レベルでは、Auth0 がサポートするアプリケーションのプロトコルのいずれかを使用して、これを実現することもできます。ただし、ほとんどの開発者は Auth0 SDK を使用します。詳しくは、Quickstartsを参照してください。 SDK の 1 つに Auth0 Lock widget があり、ユーザーのログインインターフェースを提供します。詳しくは、以下を参照してください。 Web アプリにカスタムのログイン UI を持たせたい場合は、auth0.js を使用できます。これは Auth0 用のヘッドレスな JavaScript library で、認証フロー (およびその他のタスク) を実行し、その結果としてユーザープロファイルオブジェクトを受け取ります。詳しくは、Auth0.js Referenceを参照してください。Management API からユーザープロファイルにアクセスする
Auth0 は、アプリケーションやサービスがユーザープロファイルオブジェクトにアクセスし、操作できる REST API を提供しています。 API Explorer を使用すると、Management API を対話的に確認できます。次のことが可能です。- 利用可能な API コール
- 各コールに必要な情報
- 各コールで返される情報
update:users) 、TRY をクリックします。
Auth0 Authentication API は、認証フロー専用です。詳細については、Authentication API Explorer を参照してください。通常、これらのエンドポイントのほとんどは、独自のコードではなく各種 Auth0 SDK によって使用されます。
ユーザープロファイルとトークンの違い
上記の認証フローでは、Auth0 は完全なユーザープロファイルの代わりに、一連のトークンを返します。 返されるトークンの 1 つが ID トークンです。これは、ユーザープロファイルの属性をクレームの形で含む JSON Web トークン (JWT) です。これらのクレームは、ユーザーに関する情報を表します。トークンの利用者が署名を検証できれば、そのクレームは信頼できます。この署名は (HS256 の場合) 、Auth0 app の を使って生成されます。アプリが RS256 を使用している場合、ID トークンは秘密キーで署名され、公開鍵で検証されます。その後、アプリは JWT をデコードして、そのペイロードに含まれるユーザー情報を取得できます。この情報には、ユーザー名、メールアドレス、その他通常はユーザーエクスペリエンスの一部となるデータなどが含まれます。 JWT 内のクレームには、通常、ユーザープロファイルで利用できる情報の一部しか含まれません。これは、トークンのサイズを最小限に抑えるためです。詳しくは、JSON Web Tokens をお読みください。 認証時に返されるトークンには、このほかに 3 種類あります。- Auth0
- サードパーティプロバイダーのアクセストークン