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 sources
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:
|User data from...||Might include...|
|Current employer or degrees achieved|
|Profile picture, birthday, or relationship status|
|Active Directory||Employee number, job title, or department|
Auth0 refers to all user data sources as connections because Auth0 connects to them to authenticate the user. To learn more, read Connections.
User data normalization
Auth0 supports a variety of 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
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.
User profile attribute mapping
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:
|If Auth0 is a...||Then...|
|SAML Service Provider||Use the SAML connection's Mappings tab to map attributes coming from an IDP to attributes in the Auth0 user profile: Go to Dashboard > Authentication > Enterprise > SAMLP. Click on the name of the SAML connection and click Mappings.|
|SAML Ideutity Provider||Use the Settings tab of Application AddOns to map attributes from the Auth0 user profile to attributes in the SAML Assertion sent back to the Service Provider: Go to Dashboard > Applications. Click on the name of your application, click Addons, and click SAML2 Web App.|
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.
Caching user profiles
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.
Custom user profile data
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.
Change user profile data
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
app_metadataportions 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.
Access user profiles
Both apps and the Auth0 Management API can a user's profile information.
Access user profiles from apps
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:
Access user profiles from the Management API
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.
The difference between user profiles and tokens
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
To learn more about tokens and claims, read Tokens.