Single Identity Provider: Profile Management
Profile Management in Organization-based scenarios is generally the same as in other architecture scenarios. In our architecture scenarios, we provide general purpose guidance on B2B Profile Management, which we recommend reviewing alongside the guidance provided here.
Before roles associated with a user can be managed, a user account must exist in Auth0. This is true even if you are using the Auth0 Organizations Role capability associated with Membership. However, user accounts that are provisioned via the user invitation workflow can be assigned a role automatically as part of the invitation process. For details, see the Invite Organization Members. If you’re pre-registering a user using some other mechanism, then you must store Role information outside of Auth0 and access/copy it via the use of extensibility (for example, as part of a Rule) during first authentication.
Your application may have an associated specific set of user attributes (for example, user preferences or identifying information you use to better serve the customer) for which you provide some sort of self-service management to users. Additionally/alternatively, you may provide self-service profile management for attributes that are typically maintained by the Identity Provider (IdP).
Best Practice
In organization-related scenarios, email addresses should always be verified. Consequently, you should provide self-service email verification functionality for situations in which a user’s email address cannot otherwise be verified. For further details, see Email Verification.
Database Connection
Auth0 provides you with the capability to implement self-service profile management support via the Auth0 Management API. If you are using Auth0 Organizations to provide invitation-based user provisioning, you will likely need to restrict changes to fields that are typically owned by your Auth0 Tenant as the Identity Provider (IdP). For example, you would want to restrict changes to email address because you would not want a user to use an email address other than the one to which their invitation was sent. Restricting changes to the email address field would prevent company-specific emails from going to entered personal email addresses.
Alternatively, you may want to consider providing a few self-service items for users who authenticate via a Database Connection in Auth0. You may want users to be able to:
change their email address
change any associated phone numbers
change their username
de-provision their accounts as part of regulatory compliance (such as GDPR)
perform password change processing, which we typically recommend you implement via password reset and which will typically leverage the organization-specific branding described in Branding: Password Reset Page.
Self-service capability typically needs to be implemented and hosted external to Auth0 and must be very secure.
Enterprise connection
Because the upstream Identity Provider (IdP) typically handles IdP-managed user profile attributes, profile management can be fairly non-existent for this use case. However, if you use application-specific user attributes, then you may still want to provide self-service capability.
In addition, you will almost certainly want to provide an organization with a way to de-provision users from your Auth0 Tenant. Auth0 does not communicate with an upstream IdP, except when the Auth0 SSO session expires. Because an SSO session's time to expiration will likely be too long for most scenarios in which a user is deleted, an organization administrator will need a way to block or delete a user independently.
Social connection
In the context of Social Connections, profile management follows a similar pattern to that associated with an Enterprise Connection, but the upstream IdP is associated with the social provider rather than any specific organization.
Administration
In certain situations you will want to give your customers access to manage user accounts associated with their organization. This is often true for help-desk-type scenarios in which a help desk operator may update profile information on behalf of a user or help a user unblock an account.
Out of the box, Auth0 provides the Auth0 Dashboard, which is used for general management of an Auth0 Tenant. However, you would not want to give a customer access to your Auth0 Tenant Dashboard because they would then have the ability to manage all users across all organizations, which would not be desirable.
While the Auth0 Tenant Dashboard can be used to manage user accounts, it does not provide for organizational-level isolation. Giving a customer access to your Auth0 Dashboard allows them to modify users across all organizations, which is not desirable. The Auth0 Delegated Admin dashboard can be configured to provide user account administration that is Auth0-Organization-aware; however, it cannot be used to manage user Membership or Invitation.
If you already provide help-desk-type capability for your customers, then you can use the Auth0 Management API to manage user accounts in Auth0. For example, the Management API can be used to retrieve organization members and organizations to which a user belongs. If you do not already provide help desk capability, then you will need to build this functionality if you require it.