At some point, you may need to change 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 may need to happen for a number of different reasons:
  • Self-served information updates
  • Mandatory updates concerning your organizations T’s & C’s
  • Changes due to regulatory compliance
You cannot directly access a user profile across multiple Auth0 tenants. If you’re deploying multiple Auth0 tenants to production then this is something you need to be aware of.
An Identity Provider populates a user’s profile using data supplied during the login process, and this is referred to as the Normalized User Profile.
The Normalized User Profile is updated from the identity provider during login, and you can change the limited set of the information it contains through the Auth0 Management API. You can also use Auth0 extensibility, such as Rules, as an alternative to override information in the Normalized User Profile. See User Profile Data Modification for more information.
By default, there is one user profile created for each user identity, and there are a number of things to consider:
  • What should you do if you need to store information to help customize a user’s experience?
  • What if you need to store user information that didn’t originate from an ?
  • Why would you need to store user-related information that a user cannot modify?
  • What do you do if you 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?
  • How do you provide an administrator from a third-party organization with the ability to manage their users?
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), you can leverage Auth0-provided Password Reset functionality. This can be integrated with your existing implementation and comes already incorporated with any out-of-box Auth0 UI widgets including Universal Login. You’ll also want to make sure that you are working with a verified user account at all times. Auth0 provides out-of-box mechanisms for doing that too. You should also consider regulatory compliance such as (GDPR which has very specific requirements when it comes to protecting EU citizens from privacy and data breaches. Though Auth0 doesn’t currently provide a centralized profile management portal out-of-the-box, for the purpose of self-serviced profile management, you can use the Auth0 to build your own or utilize an already built UI. See our Auth0 community guidance which describes the Management API endpoint. All 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, you can use the 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. If you need to provide a way for your customers to have an administrator manage their own users when they are storing those credentials in your system, you can either build something yourself or use an Auth0 Extension. See Admin Portal for more 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 a way to store information that overrides what an identity provider supplies.

​
Best Practice

Use of Metadata should follow Auth0 user data storage best practices. 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.
You can manipulate metadata via both the Auth0 Management API and the Auth0 Authentication API. As is the case when managing the Normalized User Profile, calls to the Management API for manipulating Metadata requires 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

Store any information that you want use to customize Auth0 emails in metadata and preferably user_metadata if the user is allowed to change it, such as information used to determine the language for an email.

​
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 could 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. You can integrate this 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 provides 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. 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. You can use the Auth0 Management API, on the other hand, to directly change the password for a user identity defined using a Database Connection type. You can use the Auth0 Management API as part of any self-service profile management implementation, and also as part of any Change Password page customization.

​
Account verification

You’ll also need to work 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 very specific requirements for protecting EU citizens from privacy and data breaches. Auth0 provides out-of-box functionality for sending a verification email to a user’s email address to verify their account. By default, Auth0 automatically sends verification emails for any Database Connection identity created as part of self sign-up. However, Auth0 also provides a Management API endpoint that you can use to send verification emails 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. You can also use Auth0 extensibility 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.

​
Admin portal

An admin portal is an application where you can create new users, edit a user’s profile, see activity about a user, etc. This application should be accessible by administrators only. Though Auth0 provides its management dashboard, it is not advised to give access to the management dashboard to many people as there are a lot of ways someone can unintentionally break your Auth0 tenant. Instead, Auth0 provides two other options:
  • Auth0 Management API: With the Management API you can easily construct an application that provides administrators the ability to manage users. You can either incorporate this into an existing application that already exists for your administrators, or create a new one with a UI that matches your current applications.
  • Auth0 Delegated Administration Extension: This powerful and flexible extension allows you to customize a user administration experience. You can tailor this extension so that you can allow your customer admins to log in and allow them to only see and manage users within their organization.

​
Best practice

If you are providing your own way for an administrator to manage users, you should only allow administrators to send users a change password link through email rather than allowing administrators to set passwords directly. If you must go against this recommendation and allow your administrators to set someone’s password, you should force the user to change their password at their next login so that only they know the password (and not an administrator as well).

​
Project Planning Guide

We provide planning guidance in PDF format that you can download and refer to for details about our recommended strategies. B2B IAM Project Planning Guide

​
Multiple Organization Architecture (Multitenancy)

Many B2B platforms implement some form of isolation and/or branding for their customers’ organization, and this can add complexity to any Identity and Access Management (IAM) system. If this applies to you, then we recommend you take some time to read through our guidance and best practice advice for this type of environment. Multiple Organization Architecture