User Profiles

To access any of the applications in your tenant, each user must have a profile in the tenant. User profiles contain information about your users such as name and contact information. You can manage user profiles through the Auth0 Dashboard and the Auth0 Management API. 

User data can come from many sources, including your own databases as well as social, legal, and enterprise identity providers. Some examples include Google, Facebook, Active Directory, or SAML. You can normalize user data that comes from any supported data source. 

User profile attributes can include information from the identity provider. These are examples:

Auth0 refers to all user data sources as connections because Auth0 connects to them to authenticate the user.

Auth0 supports a variety of Identity Providers and Database Connections. Each connection can return a different set of user attributes. Sometimes different connections use different names for the same attribute. For example, surname from one connection might be last_name and family_name from other user data sources. 

To handle this complexity, Auth0 provides a normalized user profile, an Auth0-specific standard for storing user data.

For Active Directory or any other LDAP connections that use the Auth0 AD/LDAP connector, there is a mechanism for mapping user profile attributes in the directory service to the Auth0 normalized user profile. A profileMapper.js file, located in the installation directory of the AD/LDAP connector, maps the attributes when a user authenticates.

If your application uses the SAML protocol to communicate with Auth0, one of two mechanisms match the user attributes to the Auth0 normalized user profile:

Users can log into an application initially using one connection (such as a custom database), then later log in using a different connection (such as Facebook). In this case, the user_id for the second authentication is different from the user_id for the first authentication.

Auth0 provides a mechanism to link the two accounts. When Auth0 links the two accounts, it stores two elements in the identities array portion of the user profile, one for each connection.

Auth0 does not merge user profile attributes from multiple providers. Auth0 sources core user profile attributes from the first provider used.

To learn more, read User Account Linking.

Auth0 caches the user profile received from a connection before passing it on to the calling application. This cache is in the Auth0 database. Each time the user authenticates, Auth0 updates the cache. To learn more, read Update User Profile Using Your Database.

Auth0 lets you store metadata, which is data related to each user that has not come from the identity provider. You can use user_metadata to store custom attributes such as the user's favorite color or hobby.

You can modify a user's profile information in a number of ways.

• Scopes: The authentication flows supported by Auth0 include an optional parameter that lets you specify a scope. This controls the user profile information (claims) included in the ID token (JWT).

• Auth0 Dashboard: The Dashboard lets you manually edit the user_metadata and app_metadata portions of any user’s profile.

• Management API: You can read, update, and delete user profiles stored in the Auth0 database.

• Custom database scripts: If you’re using a custom database as a connection, you can write scripts to implement lifecycle events such as create, login, verify, delete and change password. Auth0 provides templates for these scripts that you can modify for the particular database and schema.

• Rules: Use Rules to augment the user profile during the authentication transaction, and optionally persist those changes back to Auth0. 

Both apps and the Auth0 Management API can a user's profile information.

Once Auth0 completes authentication and returns control to your application, it provides the user profile to the application. At a low level, you can accomplish this using one of the application protocols supported by Auth0. However, most developers prefer to use the Auth0 SDKs. To learn more, read Quickstarts.

One SDK is the Auth0 Lock widget, which provides a user login interface. To learn more, read:

• Lock for Web

• Lock Swift

• Lock.Android

If you want your web app to have a custom login UI, you can use Auth0.js. This headless JavaScript library for Auth0 invokes authentication flow (and other tasks) and receives a User Profile object in return. To learn more, read Auth0.js v9 Reference.

Auth0 provides a REST API that allows applications and services to access and manipulate the User Profile object.

The API Explorer lets users interactively explore the Management API. It provides:

• API calls available

• Information required for each call

• Information returned by each call

With the explorer, users can try each endpoint in the explorer UI or via a CuRL command on the command line. To try one of the Management API commands, go to the API Explorer. Select the access required under Scopes within the command you choose, such as update:users, and then click TRY.

The Auth0 Authentication API is specifically for authentication flows. To learn more, read Authentication API Explorer. Typically, most of these endpoints are used by the various Auth0 SDKs, not your own code.

In the authentication flows described above, Auth0 returns a set of tokens in lieu of a full user profile.

One of the returned tokens is the ID token, which is a JSON Web Token (JWT) that contains user profile attributes represented in the form of claims. These claims are statements about the user. A claim can be trusted if the consumer of the token can verify its signature, which (in the case of HS256) is generated with the Auth0 app’s client secret. If your app uses RS256 encryption, the ID token will be signed with a private key and verified with a public key. Your app can then decode the JWT and get the user information contained in its payload. Examples of this information are the user's name, email, and other data that is typically part of the user experience.

The claims within a JWT generally contain only a subset of the information available in the user profile. The purpose is to minimize the token size. To learn more, read JSON Web Tokens.

There are three other types of tokens that can be returned during authentication:

• Auth0 access token

• Third-party provider access token

• Refresh token

To learn more about tokens and claims, read Tokens.

• Check User Profiles
• Troubleshoot Custom Domains
• Troubleshoot SAML Errors
• Verify Connections
• Check API Calls
• Auth0.Android Login, Logout, and User Profiles