> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

> Understand how user profiles work in Auth0.

# 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](/docs/get-started/auth0-overview/dashboard) and the [Auth0 Management API](https://auth0.com/docs/api/management/v2).

## User data sources

User data can come from many sources, including your own databases as well as social, legal, and enterprise <Tooltip tip="Identity Provider (IdP): Service that stores and manages digital identities." cta="View Glossary" href="/docs/glossary?term=identity+providers">identity providers</Tooltip>. Some examples include Google, Facebook, Active Directory, or <Tooltip tip="Identity Provider (IdP): Service that stores and manages digital identities." cta="View Glossary" href="/docs/glossary?term=SAML">SAML</Tooltip>. 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...                                  |
| ----------------- | ------------------------------------------------- |
| LinkedIn          | Current employer or degrees achieved              |
| Facebook          | 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.

### User data normalization

Auth0 supports a variety of [Identity Providers](/docs/authenticate/identity-providers) and [Database Connections](/docs/authenticate/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](/docs/manage-users/user-accounts/user-profiles/normalized-user-profiles), an Auth0-specific standard for storing user data.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  To view the Auth0 [user profile data structure](/docs/manage-users/user-accounts/user-profiles/user-profile-structure), go to [Dashboard > User Management > Users](https://manage.auth0.com/#/users) and then click on a user.
</Callout>

### User profile attribute mapping

#### AD/LDAP connector

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.

#### SAML assertions

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](https://manage.auth0.com/#/connections/database/enterprise/samlp). Click on the name of the SAML connection and click **Mappings**.                                      |
| SAML Identity 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](https://manage.auth0.com/#/connections/database/applications). Click on the name of your application, click **Addons**, and click **SAML2 Web App**. |

### Account linking

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](/docs/manage-users/user-accounts/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](/docs/manage-users/user-accounts/user-profiles/update-user-profiles-using-your-database).

## Custom user profile data

Auth0 lets you store [metadata](/docs/manage-users/user-accounts/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](/docs/get-started/apis/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 <Tooltip tip="JSON Web Token (JWT): Standard ID Token format (and often Access Token format) used to represent claims securely between two parties." cta="View Glossary" href="/docs/glossary?term=ID+token">ID token</Tooltip> (<Tooltip tip="ID Token: Credential meant for the client itself, rather than for accessing a resource." cta="View Glossary" href="/docs/glossary?term=JWT">JWT</Tooltip>).
* [Auth0 Dashboard](/docs/manage-users/user-accounts/manage-users-using-the-dashboard): The Dashboard lets you manually edit the `user_metadata` and `app_metadata` portions of any user’s profile.
* [Management API](/docs/manage-users/user-accounts/manage-users-using-the-management-api): You can read, update, and delete user profiles stored in the Auth0 database.
* [Custom database scripts](/docs/authenticate/database-connections/custom-db/templates): 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](/docs/manage-users/user-accounts/metadata/manage-metadata-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 <Tooltip tip="Management API: A product to allow customers to perform administrative tasks." cta="View Glossary" href="/docs/glossary?term=Management+API">Management API</Tooltip> can access 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](/docs/authenticate/protocols) supported by Auth0. However, most developers prefer to use the Auth0 SDKs. To learn more, read [Quickstarts](/docs/quickstarts).

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

* [Lock for Web](/docs/libraries/lock)
* [Lock Swift](/docs/libraries/lock-swift)
* [Lock.Android](/docs/libraries/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 Reference](/docs/libraries/auth0js).

### 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](https://auth0.com/docs/api/management/v2). 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](https://auth0.com/docs/api/authentication). 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 <Tooltip tip="Client Secret: Secret used by a client (application) to authenticate with the Authorization Server; it should be known to only the client and the Authorization Server and must be sufficiently random to not be guessable." cta="View Glossary" href="/docs/glossary?term=client+secret">client secret</Tooltip>. 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](/docs/secure/tokens/json-web-tokens).

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

* Auth0 <Tooltip tip="Access Token: Authorization credential, in the form of an opaque string or JWT, used to access an API." cta="View Glossary" href="/docs/glossary?term=access+token">access token</Tooltip>
* Third-party provider access token
* <Tooltip tip="Refresh Token: Token used to obtain a renewed Access Token without forcing users to log in again." cta="View Glossary" href="/docs/glossary?term=Refresh+token">Refresh token</Tooltip>

To learn more about tokens and claims, read [Tokens](/docs/secure/tokens).

## Learn more

* [Auth0.Android Login, Logout, and User Profiles](/docs/libraries/auth0-android/auth0-android-login-logout-and-user-profiles)