apps/docs/content/concepts/features/selfservice.mdx
ZITADEL allows users to perform many tasks themselves. For these tasks we either provide a user interface, or the tasks can be initiated or completed through ZITADEL's APIs.
It is important to understand that, depending on your use case, there will exist different user-types that want to perform different actions:
Users are the end-users of your application. Like with any CIAM solution, users should be able to perform tasks like register/join, update their profile, manage authenticators, etc. There are certain actions that can be executed pre-login, yet others require the user to have a valid session.Administrators are users with a special administrator role within ZITADEL and can perform administrative actions such as organization settings or granting access rights to users.All self-service interfaces are available in different languages.
<Callout> ZITADEL covers the typical "CIAM" self-service capabilities as well as delegated access management for multi-tenancy scenarios. Please refer to the section [Administrators](#administrators). </Callout>Allows anonymous users and authenticated users, who are not yet in the given organization, to create an account (register) themselves.
The user is prompted on the first login to set up MFA. This step can be made mandatory if MFA is enforced in the login policy.
Anonymous users and authenticated users, who are not yet in the given organization, to register with an external identity provider. An external identity provider can be a Social Login Provider or a pre-configured identity provider.
When you log in with an external identity provider, and the user does not exist in ZITADEL, then an autoregister flow is triggered. The user is presented with two options:
Given an external identity provider is configured on the instance or on the organization, then:
Service acounts can't use an interactive login but require other means of authentication, such as privately signed JWT or personal access tokens. Read more about Service Accounts and recommended OpenID Connect Flows.
Users can terminate the session for all their users (logout). An application can also implement this by calling the specific endpoint.
These actions are available for authenticated users only. ZITADEL provides a self-service UI for the user profile out-of-the box under the path $CUSTOM_DOMAIN/ui/console/users/me. You can also implement your own version in your application by using our APIs.
Users can change their passwords. The current password must be entered first.
Users can set up and delete a second factor and FIDO Passkeys (Passwordless). Available authenticators are:
Users can change their profile information. This includes
Users can change their email address. The user receives an OTP and can verify control over the given email address.
Users can change their phone number. The user receives an OTP and can verify control over the given phone number.
Users can create a connection between a local user account and an external identity. The user can log in with any of the linked accounts. Linking of external accounts is done during the login process.
It is important to note that an Administrator is not simply an administrative user, but can be used to create much more advanced scenarios such as delegating administration of a whole organization to a user, acting then as administrator and permission manager of that user group.
Thus, we will explain service for two of the most common scenarios in ZITADEL:
Administrators in isolation: Granting administrative permissions within a single organization context.Administrators in delegation: Granting administrative permissions to a user from a different organization where the organizations depend on each otherA list of Administrator Roles is available with a description of permissions. Administrators can be assigned to both human users and service accounts, e.g., for managing certain tasks programmatically.
A user with Administrator roles IAM_OWNER or ORG_OWNER might want to assign other users from their organization elevated permissions to handle certain aspects of the IAM tasks.
This could be permission to assign authorizations within this isolated organization (ORG_USER_MANAGER) or handling setup of projects and applications (PROJECT_OWNER).
In a setup like described in the B2B Scenario, there exists an organization of the project owner and a customer organization. The project is granted to the customer organization, such that the customer can access the project and assign authorization to their users.
Given such as set up the owner might want to give one administrative user of the customer organization the role ORG_OWNER.
Equipped with this Administrator Role, the user can perform actions like configuring their own SSO/Identity Provider, set security policy for their organization, customize branding, or assign project or Administrator roles to other users.
An ORG_OWNER can also not only delegate Administrator roles to other users as described in the earlier section but also manage all aspects of their own organization as well as authorize users to use the granted project.
With ZITADEL there is no need to replicate all settings and projects across organizations.
Instead, you could set up the project in one organization, delegate it to different organizations, and then appoint users as Administrators of that organization to allow for self-service in a multi-tenancy scenario.