mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-22 23:42:16 +00:00
cc7a6145f1
# Which Problems Are Solved As part of the naming consistency initiative, the terms `Manager`, `Member` and other similar terms that are used in the context of an administrator are replaced by `Administrator` in the UI and documentation. # How the Problems Are Solved By replacing the following terms with Administrator / Administrator Roles in docs, Console UI, and guides. - Manager - Add Manager - Add a Manager - Administrator (used as a person type) - Membership - Member grants # Additional Changes minor grammatical edits in the docs # Additional Context - Closes https://github.com/zitadel/zitadel/issues/11291 --------- Co-authored-by: Marco A. <[email protected]>
58 lines
2.6 KiB
Plaintext
58 lines
2.6 KiB
Plaintext
---
|
|
title: ZITADEL Users
|
|
sidebar_label: Users
|
|
---
|
|
|
|
import CreateUser from './_create-user.mdx';
|
|
|
|
ZITADEL differs two different types of users:
|
|
|
|
- Users (Humans)
|
|
- Service Users (Machine Accounts)
|
|
|
|
<img src="/docs/img/guides/console/usersmenu.png" width="420px" alt="User types" />
|
|
|
|
A user has an email address and a password, and can additionally save information about phone, nickname, gender, language.
|
|
A service account only has a name and a description aside his username.
|
|
|
|
A service account can be authenticated with JWT profile or Personal Access Tokens. Both methods can specify an expiry.
|
|
A user can authenticate itself with his password, add multiple factors for additional security, and enable passkey authentication.
|
|
|
|
Service users are primarily used to gain access for a backend service or iot device. The fact that service accounts can also be ZITADEL administrators is used to restrict access to specific projects or organizations.
|
|
To get an understanding on how service accounts are used, take a look at our NextJS B2B Demo application.
|
|
|
|
## Create User
|
|
|
|
<CreateUser components={props.components} />
|
|
|
|
## Metadata
|
|
|
|
When building complex applications, having the possibility to add metadata is essential.
|
|
ZITADEL provides a key value storage for users on the user pages.
|
|
Just navigate to the section **Metadata** and click on **edit**.
|
|
|
|
> In our [Point of Sales example](./projects#example) from the projects guide, you could add a `stripeCustomerId` as a metadata key. In your client application you could then easily fetch the customer from Stripe APIs for your payments.
|
|
|
|
<img
|
|
width="460px"
|
|
src="/docs/img/guides/console/usermetadata.png"
|
|
alt="User Metadata"
|
|
/>
|
|
|
|
Metadata can be requested via our auth and management APIs, from userinfo endpoint or ID Token.
|
|
To get your metadata from the userinfo endpoint, add `urn:zitadel:iam:user:metadata` to your authentication request. Take a look at our reserved scopes [here](/apis/openidoauth/scopes#reserved-scopes) or take a look at our [metadata guide](../customize/user-metadata).
|
|
|
|
You can then toggle **User Info inside ID Token** in your application settings if you need this information in the ID Token too.
|
|
|
|
<img
|
|
src="/docs/img/guides/console/appidtokensettings.png"
|
|
width="650px"
|
|
alt="ID Token settings"
|
|
/>
|
|
|
|
## Authorizations
|
|
|
|
As described in [Roles and Authorizations](./roles), authorizations are shown on user profile pages too.
|
|
If you need user roles in the user info endpoint, check the **Assert roles on authentication** checkbox in your project as described in [Authorizations](./roles#authorizations).
|
|
If you need them in your ID Token, toggle **User roles inside ID Token** in application settings.
|