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.
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).
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.
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.
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.
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.
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.