Docs

Profile Management

At some point, you’ll need to manage change to the information stored in a user’s Profile. A user’s profile--also known as the user’s Account--is stored in Auth0, and changes to the information it contains can be required for a number of different reasons: self-served information update, mandatory updates concerning your organizations T's & C’s, and changes due to regulatory compliance are just some of the things you’ll need to consider.

A user profile cannot be directly accessed across multiple Auth0 tenants, so if you’re deploying multiple Auth0 tenants to production then this is something you need to be aware of.

A user’s profile is populated from data supplied by an Identity Provider during the login process, and this is referred to as the Normalized User Profile. By default, there is one user profile created for each user identity, and there are a number of things to consider when looking at the management of it:

The Normalized User Profile is updated from the identity provider during login, and a limited set of the information it contains can be changed through the Auth0 Management API. Auth0 extensibility, such as Rules, can be used as an alternative to override information in the Normalized User Profile as described in the Auth0 guidance provided.

  • What should I do if I need to store information to help customize a user’s experience?
  • What if I need to store user information that didn’t originate from an identity provider?
  • Why would I need to store user-related information that a user cannot modify?
  • What do I do if I need to store user-related information that a user cannot modify?
  • What happens if a user forgets their password?
  • What should a user do if they want to change their password?

Auth0 provides for the storage of Metadata against a user’s profile, which allows for the capture of additional information, such as preference for language and/or accessibility in order to enhance the user experience. Metadata can be used to store both information that a user can change, and also information they can’t; the latter giving you the capability of associating, for example, a user profile with records in your existing systems without modifying existing implementation.

For users who forget their passwords or who are allowed to change their password via some existing self-service mechanism (or self-service mechanism you have planned), Auth0-provided Password Reset functionality can be leveraged. This can be integrated with your (existing) implementation and comes already incorporated with any out-of-box Auth0 UI widgets included as part of Universal Login.

You’ll also want to make sure that you are working with a verified user account at all times, and Auth0 provides out-of-box mechanisms for doing that too. There is also regulatory compliance to be considered (GDPR, for example, has some very specific requirements when it comes to protecting all EU citizens from privacy and data breaches) and guidance concerning this is also provided.

Though Auth0 doesn’t currently provide any form of centralized profile management portal out-of-the-box, for the purpose of self-serviced profile management, the Auth0 Management API can be leveraged to build your own (or utilize an already built) UI, and Auth0 community guidance describes in further detail the Management API endpoint for doing this. N.B. calls to the Management API will require use of an Access Token.

Self-service profile management can raise security as well as data privacy concerns. For example, you may want to allow a user to change their email address; however, doing so without following best practice security guidance could result in a user locking themselves out of their account, leaking Personally Identifiable Information (PII), or worse, opening up a potential breach in security.

Alternatively, the Auth0 Dashboard can be used to manage aspects of a user’s profile. Managing a user’s profile via the Auth0 Dashboard is more of an administrative provision and should not be used for self-serviced profile management in a production environment. However, the interface provided by the Dashboard can be extremely useful during development as it provides a quick and simple way of manipulating a user’s profile information.

Metadata

In addition to the Normalized User Profile information, Metadata can be stored in an Auth0 user profile. Metadata provides a way to store information that did not originate from an identity provider, or can be used as a way to store information that overrides what an identity provider supplied.

Best Practice

Use of Metadata should follow Auth0 best practice guidance. Metadata storage is not designed to be a general purpose data store, and you should still use your own external storage facility when possible. Metadata size and complexity should also be kept to a minimum, and the Auth0 Management API has a strict set of guidance when it comes to updating and/or deleting metadata associated with a user.

Metadata can be manipulated via both the Auth0 Management API and the Auth0 Authentication API, and the documentation provided further describes the endpoints for doing this. As is the case when managing the Normalized User Profile, calls to the Management API for manipulating Metadata will require use of an Access Token.

Calls to the Management API are subject to Auth0 Rate Limiting policy. You must take this into consideration, and to assist, Auth0 generally recommends use of the appropriate Auth0 SDK for your development environment rather than calling our APIs directly.

User metadata

User metadata (also referred to as user_metadata) is information that can be stored against a user profile and that a user can read and update as part of any self-service profile management. Metadata of this nature may be something like salutation for a user, or a user’s preferred language (which could be used to customize the emails sent by Auth0).

Best Practice

Any information that will be used to customize Auth0 emails, such as information used to determine the language for an email, should be stored in metadata and preferably user_metadata if the user is allowed to change it.

App metadata

App metadata (also referred to as app_metadata) is, on the other hand, information that can be stored with a user profile but can only be read or updated with appropriate authorization; app_metadata is not directly accessible to a user. This type of metadata might be something like a flag to indicate that the last set of valid terms and conditions was accepted by the user, and a date to indicate when the user accepted them.

Password reset

For users who forget their passwords or who are allowed to change their password via some existing self-service mechanism, Auth0 provides Password Reset functionality. This can be integrated with your (existing) implementation and comes already incorporated with out-of-the-box Auth0 UI widgets included as part of Universal Login.

Password change and password reset is only supported for Auth0 Database Connection types.

Auth0 Universal Login widgets provide built-in UX support for password reset using Auth0 Authentication API functionality. Alternatively, you can use the Auth0 Authentication API, through one of the Auth0 SDKs appropriate to your development environment if you are using Universal Login advanced customization. Email templates used during password reset workflow can also be fully customized whether you use Auth0 out-of-box UI widgets or customized Universal Login.

The Auth0 Management API, on the other hand, can be used to directly change the password for a user identity defined using a Database Connection type. The Auth0 Management API can be used as part of any self-service profile management implementation, and is also used as part of any Change Password page customization.

Account verification

You’ll also want to make sure that you are working with a verified user account at all times, and make use of the mechanisms Auth0 provides. You should also consider regulatory compliance like GDPR, which has some very specific requirements when it comes to protecting all EU citizens from privacy and data breaches and guidance.

Auth0 provides out-of-box functionality for sending a verification email to a user's email address as one way of verifying their account. By default, Auth0 is configured to automatically send verification emails for any Database Connection identity created (e.g., as part of self sign-up). However, Auth0 also provides a Management API endpoint that can also be used to send verification emails (e.g., in cases where email address validation is not performed by a Social Provider upon user registration).

Blocking users

Blocking user access in Auth0 provides a way to prevent user login to applications under certain conditions. By default, the Auth0 Dashboard provides an out-of-the-box mechanism to give administrators the ability to both block and unblock user access to all applications, and you can implement this functionality via use of the Auth0 Management API. Auth0 extensibility can also be used to disable user access to certain applications as well as provide more fine-grained access control.

In addition, the Auth0 Management API provides you with the ability to unblock users disabled due to excessive use of incorrect credentials.

Linking user accounts

By default, there is one user profile (i.e., one user account) for each user identity. If you enable login from multiple identity providers--via, say, Facebook or Google social authentication as well as via Auth0 username and password authentication --then each will have a separate user profile. Auth0’s functionality for linking user accounts (a.k.a. account linking) can be used to create one profile for a user, as an aggregate of all their associated identities.

The process of linking accounts essentially merges user profiles in pairs: a primary account and a secondary account must be specified in the linking process. The number of accounts that can be linked, however, extends beyond a single pair. For example, an account which already has multiple accounts merged with it can be used as the primary, and an additional secondary account can be linked to it. This means that one user account can have multiple identities associated with it, which additionally provides a number of advantages:

  • Allows users to log in using multiple identities without creating a separate profile for each
  • Allows registered users to use new login identities, but continue using their existing profile
  • Allows users to carry their profile around, irrespective of which identity they use for login
  • Allows users to link to an account with more identity information in order to provide a more complete profile
  • Allows your apps to retrieve connection-specific user profile data

De-provisioning

Your application may need to support a user’s request to remove their account (for example, you might need to meet GDPR requirements). You can implement such a feature, along with a number of other profile-related functions, using the Management API. The Management API allows you to retrieve information stored about a user and update it as required.

Auth0 is capable of supporting various privacy-related requirements, including the display of links to consent notices on signup and data protection to support the rights of users to view and correct data you’ve collected about them.

GDPR and other privacy directives require that users have the right to view and correct data held about them. They also have the right to be “forgotten.” You can use the Management API to address these requirements and meet your legislative obligations.

Planning

To help you with planning your implementation, we've put together some planning guidance that details our recommended strategies.

Keep reading