mirror of
https://github.com/andwati/zitadel.git
synced 2026-11-07 22:55:12 +00:00
chore(docs): User (Human) naming consistency (#11512)
# Which Problems Are Solved Naming inconsistencies - User (Human) # How the Problems Are Solved Most of the occurrences have not been changed. `User (Human)` was mostly changed when talking about code objects and where I felt it was necessary to distinguish them from machine users. When both human and machine user occurrences were found, the machine user has been changed to service account (see https://github.com/zitadel/zitadel/issues/11285) # Additional Context - Closes #11284 --------- Co-authored-by: Wim Van Laer <[email protected]>
This commit is contained in:
Marco A.
Wim Van Laer
@@ -77,7 +77,7 @@ The trigger is represented by the following Ids in the API: `TRIGGER_TYPE_PRE_CR
|
||||
- `ctx`
|
||||
The first parameter contains the following fields
|
||||
- `v1`
|
||||
- `user` [*human*](./objects#human-user)
|
||||
- `user` [*(human)*](./objects#human-user)
|
||||
- `authRequest` [*auth request*](/apis/actions/objects#auth-request)
|
||||
- `httpRequest` [*http request*](/apis/actions/objects#http-request)
|
||||
- `org`
|
||||
|
||||
@@ -63,8 +63,8 @@ title: Objects
|
||||
- `username` *string*
|
||||
- `loginNames` Array of *string*
|
||||
- `preferredLoginName` *string*
|
||||
- `human`
|
||||
Set if the user is human
|
||||
- `human`
|
||||
Set if User (Human)
|
||||
- `firstName` *string*
|
||||
- `lastName` *string*
|
||||
- `nickName` *string*
|
||||
|
||||
@@ -14,7 +14,7 @@ The [OpenID Connect & OAuth endpoints](/apis/openidoauth/endpoints) and [SAML 2.
|
||||
|
||||
## Authentication & authorization
|
||||
|
||||
### Authentication for human users (interactive)
|
||||
### Authentication for users (interactive)
|
||||
|
||||
ZITADEL implements industry standards such as OpenID Connect, OAuth 2.0, or SAML for authentication.
|
||||
Please refer to our guides how to [authenticate users](/guides/integrate/login/login-users) through an interactive authentication process.
|
||||
@@ -23,10 +23,10 @@ For user authentication on devices with limited accessibility (eg, SmartTV, Smar
|
||||
|
||||
Additionally, you can use the [session API](/reference/api/session) to authenticate users, for example by building a [custom login UI](/guides/integrate/login-ui).
|
||||
|
||||
### Authenticate service users and machines
|
||||
### Authenticate service accounts
|
||||
|
||||
Service users allow for machine-to-machine (M2M) communication.
|
||||
Follow the guides to learn how to [authenticate service users](/guides/integrate/service-users/authenticate-service-users).
|
||||
Follow the guides to learn how to [authenticate service accounts](/guides/integrate/service-accounts/authenticate-service-accounts).
|
||||
|
||||
Accessing the ZITADEL APIs through a service user might require additional steps, please follow the guide on how to [access ZITADEL APIs](../guides/integrate/zitadel-apis/access-zitadel-apis) to include the correct audience scope in your requests.
|
||||
|
||||
|
||||
@@ -98,8 +98,8 @@ No major changes have been made to the organization requests.
|
||||
When migrating your user management from v1 to v2, the most significant updates involve user states and the initial onboarding process:
|
||||
|
||||
- **Unified User Creation Endpoint**:
|
||||
- A significant simplification in v2 is the consolidation of user creation. There is now one primary endpoint for creating users, regardless of whether they are human or machine users.
|
||||
- You can use this single endpoint to provision both human users (individuals interacting with your application) and machine users (e.g., service accounts, API clients), typically by specifying the user type in the request payload.
|
||||
- A significant simplification in v2 is the consolidation of user creation. There is now one primary endpoint for creating users, regardless of whether they are User (Human) or machine users.
|
||||
- You can use this single endpoint to provision both users (individuals interacting with your application) and service accounts (i.e. API clients), typically by specifying the user type in the request payload.
|
||||
- **No More "Initial" State**:
|
||||
- In v1, new users without a password or verified email were automatically assigned an initial state. This default assumption wasn't always ideal.
|
||||
- In v2, this initial state has been removed. All newly created users are now active by default, regardless of their initial attributes.
|
||||
|
||||
@@ -31,7 +31,7 @@ The base URL for the SCIM endpoint in Zitadel is: `https://${CUSTOM_DOMAIN}/scim
|
||||
## Authentication
|
||||
|
||||
The SCIM interface adheres to Zitadel's standard API authentication methods.
|
||||
For detailed instructions on authenticating with the SCIM interface, refer to the [Authenticate Service Users Guide](/guides/integrate/service-users/authenticate-service-users).
|
||||
For detailed instructions on authenticating with the SCIM interface, refer to the [Authenticate Service Users Guide](/guides/integrate/service-accounts/authenticate-service-accounts).
|
||||
|
||||
## Query
|
||||
|
||||
@@ -826,7 +826,7 @@ curl -G "https://${DOMAIN}/scim/v2/${ORG_ID}/ServiceProviderConfig" \
|
||||
"name": "Zitadel authentication token",
|
||||
"description": "Authentication scheme using the OAuth Bearer Token Standard",
|
||||
"specUri": "https://www.rfc-editor.org/info/rfc6750",
|
||||
"documentationUri": "https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users",
|
||||
"documentationUri": "https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts",
|
||||
"type": "oauthbearertoken",
|
||||
"primary": false
|
||||
}
|
||||
|
||||
@@ -62,14 +62,14 @@ The Command Side has some unique requirements, these include:
|
||||
##### Command Handler
|
||||
|
||||
The command handler receives all operations who alter a resource managed by Zitadel.
|
||||
For example if a user changes his name. The API Layer will pass the instruction received through the API call to the command handler for further processing.
|
||||
For example if a user changes their name. The API Layer will pass the instruction received through the API call to the command handler for further processing.
|
||||
The command handler is then responsible of creating the necessary commands.
|
||||
After creating the commands the command hand them down to the command validation.
|
||||
|
||||
##### Command Validation
|
||||
|
||||
With the received commands the command validation will execute the business logic to verify if a certain action can take place.
|
||||
For example if the user really can change his name is verified in the command validation.
|
||||
For example if the user can really change their name is verified in the command validation.
|
||||
If this succeeds the command validation will create the events that reflect the changes.
|
||||
These events now are being handed down to the storage layer for storage.
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ Since everything that is available in Management Console can also be called with
|
||||
- [Event API Guide](/guides/integrate/zitadel-apis/event-api)
|
||||
- [API Documentation](/reference/api/admin)
|
||||
|
||||
Access to the API is possible with a [Service User](/guides/integrate/service-users/authenticate-service-users) account, allowing you to integrate the events with your own business logic.
|
||||
Access to the API is possible with a [Service User](/guides/integrate/service-accounts/authenticate-service-accounts) account, allowing you to integrate the events with your own business logic.
|
||||
|
||||
## Using logs in external systems
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ Given an external identity provider is configured on the instance or on the orga
|
||||
### Machines
|
||||
|
||||
Machine accounts 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 Users](/guides/integrate/service-users/authenticate-service-users) and recommended [OpenID Connect Flows](/guides/integrate/login/oidc/oauth-recommended-flows#different-client-profiles).
|
||||
Read more about [Service Users](/guides/integrate/service-accounts/authenticate-service-accounts) and recommended [OpenID Connect Flows](/guides/integrate/login/oidc/oauth-recommended-flows#different-client-profiles).
|
||||
|
||||
## Logout
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
Managers are [human users or service users](/guides/manage/console/users-overview) who have permission to manage resources within ZITADEL.
|
||||
Managers are [users or service accounts](/guides/manage/console/users-overview) who have permission to manage resources within ZITADEL.
|
||||
|
||||
Manager permissions can be assigned to different levels in ZITADEL:
|
||||
|
||||
|
||||
@@ -14,4 +14,4 @@ ZITADEL allows you to give other organizations permission to manage certain aspe
|
||||
|
||||
|
||||
|
||||
Each organization has its own pool of usernames, which includes human and service users, for its domain (`{username}@{OrganizationDomain}.$CUSTOM_DOMAIN`). A username is unique within your organization. You can configure ZITADEL to use your own domain, and simplify user experience (`{loginname}@{yourdomain.tld}`).
|
||||
Each organization has its own pool of usernames, which includes users and service accounts, for its domain (`{username}@{OrganizationDomain}.$CUSTOM_DOMAIN`). A username is unique within your organization. You can configure ZITADEL to use your own domain, and simplify user experience (`{loginname}@{yourdomain.tld}`).
|
||||
|
||||
@@ -6,12 +6,12 @@ sidebar_label: Users
|
||||
## Types of users
|
||||
|
||||
ZITADEL supports authentication and authorization for different user types.
|
||||
We can mainly differentiate between Human Users and Machine Users.
|
||||
We can mainly differentiate between Users and Service Accounts.
|
||||
We typically call human users simply "Users" and machine users "Service Users".
|
||||
|
||||
### Human users
|
||||
### Users
|
||||
|
||||
Human users typically logon with an interactive login.
|
||||
Users typically logon with an interactive login.
|
||||
This means that an application redirects a user to a website ("login page") where the user can provide the credentials.
|
||||
ZITADEL handles the authentication and provides the application with a token that verifies the authentication process.
|
||||
|
||||
@@ -21,13 +21,13 @@ Read more on how to [login users with ZITADEL](/guides/integrate/login/login-use
|
||||
|
||||
Service users are for machine-to-machine communication and you would use those typically to access secure backend services.
|
||||
For example in ZITADEL you would require an authenticated Service User to access the Management API.
|
||||
The main difference between human and machine users is the type of credentials that can be used for authentication: Human users typically logon via an login prompt, but Machine users require a non-interactive logon process.
|
||||
The main difference between users and service accounts is the type of credentials that can be used for authentication: users typically logon via an login prompt, but service accounts require a non-interactive logon process.
|
||||
|
||||
Learn how to [use service users](/guides/integrate/service-users/authenticate-service-users) with ZITADEL.
|
||||
Learn how to [use service accounts](/guides/integrate/service-accounts/authenticate-service-accounts) with ZITADEL.
|
||||
|
||||
### Managers
|
||||
|
||||
Any user, human or service user, can be given a [Manager](/concepts/structure/managers) role.
|
||||
Any user or service account can be given a [Manager](/concepts/structure/managers) role.
|
||||
A user with an administrator role is not only an end-user of ZITADEL but can also manage certain aspects of ZITADEL itself.
|
||||
|
||||
### Federated users
|
||||
|
||||
@@ -263,7 +263,7 @@ To call the API you need an access token, which is then verified by ZITADEL.
|
||||
Please follow [this guide here](/guides/integrate/token-introspection/private-key-jwt), ignoring the first step as we already have the `.json`-key-file from the serviceaccount.
|
||||
|
||||
<Callout>
|
||||
You can also create a PAT for the serviceuser and use it to test the API. For this, follow [this guide](/guides/integrate/service-users/personal-access-token#create-a-service-user-with-a-pat).
|
||||
You can also create a PAT for the serviceuser and use it to test the API. For this, follow [this guide](/guides/integrate/service-accounts/personal-access-token#create-a-service-user-with-a-pat).
|
||||
</Callout>
|
||||
|
||||
Optionally set the token as an environment variable:
|
||||
|
||||
@@ -15,7 +15,7 @@ The API will validate the access token on the [introspect endpoint](/apis/openid
|
||||
|
||||
The API application uses [Client Secret Basic](/apis/openidoauth/authn-methods#client-secret-basic) to authenticate against ZITADEL and access the introspection endpoint.
|
||||
You can use any valid access_token from a user or service account to send requests to the example API.
|
||||
In this example we will use a service account with a [personal access token](/guides/integrate/service-users/personal-access-token) which can be used directly to access the example API.
|
||||
In this example we will use a service account with a [personal access token](/guides/integrate/service-accounts/personal-access-token) which can be used directly to access the example API.
|
||||
|
||||
## Running the example
|
||||
|
||||
@@ -186,7 +186,7 @@ CLIENT_SECRET = "NVAp70IqiGmJldbS...."
|
||||
|
||||
|
||||
|
||||
1. Create a service user and a Personal Access Token (PAT) for that user by following [this guide](/guides/integrate/service-users/personal-access-token#create-a-service-user-with-a-pat).
|
||||
1. Create a service user and a Personal Access Token (PAT) for that user by following [this guide](/guides/integrate/service-accounts/personal-access-token#create-a-service-user-with-a-pat).
|
||||
2. To enable authorization, follow [this guide](/guides/manage/console/roles) to create a role `read:messages` on your project.
|
||||
3. Next, create an authorization for the service user you created by adding the role `read:messages` to the user. Follow this [guide](/guides/manage/console/roles#authorizations) for more information on creating an authorization.
|
||||
|
||||
|
||||
@@ -117,7 +117,7 @@ curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
|
||||
## Example call
|
||||
|
||||
Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or
|
||||
by calling the ZITADEL API to create a human user.
|
||||
by calling the ZITADEL API to create a user.
|
||||
|
||||
```shell
|
||||
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
|
||||
|
||||
@@ -171,7 +171,7 @@ curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
|
||||
## Example call
|
||||
|
||||
Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or
|
||||
by calling the ZITADEL API to create a human user.
|
||||
by calling the ZITADEL API to create a user.
|
||||
|
||||
```shell
|
||||
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
|
||||
|
||||
@@ -152,7 +152,7 @@ You can do this by using **Webhook.site** (see [Creating a Listener with Webhook
|
||||
## Example call
|
||||
|
||||
Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or
|
||||
by calling the ZITADEL API to create a human user.
|
||||
by calling the ZITADEL API to create a user.
|
||||
|
||||
```shell
|
||||
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
|
||||
|
||||
@@ -121,7 +121,7 @@ curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
|
||||
## Example call
|
||||
|
||||
Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or
|
||||
by calling the ZITADEL API to create a human user.
|
||||
by calling the ZITADEL API to create a user.
|
||||
|
||||
```shell
|
||||
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
|
||||
|
||||
@@ -121,7 +121,7 @@ curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
|
||||
## Example call
|
||||
|
||||
Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or
|
||||
by calling the ZITADEL API to create a human user.
|
||||
by calling the ZITADEL API to create a user.
|
||||
|
||||
```shell
|
||||
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
|
||||
|
||||
@@ -137,7 +137,7 @@ curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
|
||||
|
||||
## 7. Example Call
|
||||
|
||||
Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or by calling the ZITADEL API to create a human user.
|
||||
Now that you have set up the target and execution, you can test it by creating a user through the Management Console UI or by calling the ZITADEL API to create a user.
|
||||
|
||||
Here, we are creating a user via the API:
|
||||
|
||||
|
||||
@@ -178,7 +178,7 @@ You can also activate the v2 login for your apps, so users are redirected to `/u
|
||||
|
||||
The simplest way to deploy the new login for yourself is by using the [Deploy with Vercel button](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#login-deploy) to deploy the login directly to your Vercel.
|
||||
|
||||
1. [Create a service user](/guides/integrate/service-users/personal-access-token#create-a-service-user-with-a-pat) with a PAT in your instance
|
||||
1. [Create a service user](/guides/integrate/service-accounts/personal-access-token#create-a-service-user-with-a-pat) with a PAT in your instance
|
||||
2. Give the user IAM_LOGIN_CLIENT Permissions in the default settings (CUSTOM_DOMAIN/ui/console/instance?id=organizations)
|
||||
Note: [Zitadel Manager Guide](/guides/manage/console/managers)
|
||||
3. Deploy login to Vercel: You can do so by directly clicking the [“Deploy” button](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#login-deploy) in our [repository](https://github.com/zitadel/zitadel)
|
||||
|
||||
@@ -12,7 +12,7 @@ Roles are critical to managing permissions in a single-tenant or multi-tenant ap
|
||||
|
||||
## Assign roles and memberships
|
||||
|
||||
Human or service users can be assigned roles. You can do this via the ZITADEL Management Console or the ZITADEL APIs. As mentioned earlier, there are two types of roles in ZITADEL. You can have your own application-specific roles, and alternatively, ZITADEL also has administrator roles, such as `ORG_OWNER` and `IAM_OWNER`.
|
||||
Users or service accounts can be assigned roles. You can do this via the ZITADEL Management Console or the ZITADEL APIs. As mentioned earlier, there are two types of roles in ZITADEL. You can have your own application-specific roles, and alternatively, ZITADEL also has administrator roles, such as `ORG_OWNER` and `IAM_OWNER`.
|
||||
|
||||
Follow the links below to assign roles to your users.
|
||||
|
||||
@@ -27,12 +27,12 @@ Roles can be requested via our auth and management APIs, from userinfo endpoint
|
||||
|
||||
### Generate a token
|
||||
|
||||
You must first of all generate a token for the user. For human users, the typical approach involves using a front-end application and logging in through the browser or device. An access token will be returned after they log in successfully. A machine user will use a script or other program to generate a token using the JWT profile or client credentials grant types.
|
||||
You must first of all generate a token for the user. For users, the typical approach involves using a front-end application and logging in through the browser or device. An access token will be returned after they log in successfully. A service account will use a script or other program to generate a token using the JWT profile or client credentials grant types.
|
||||
|
||||
How to generate a token:
|
||||
|
||||
- [Generate tokens for human users](/guides/integrate/login/oidc/login-users)
|
||||
- [Generate tokens for service users](/guides/integrate/service-users/authenticate-service-users)
|
||||
- [Generate tokens for users](/guides/integrate/login/oidc/login-users)
|
||||
- [Generate tokens for service accounts](/guides/integrate/service-accounts/authenticate-service-accounts)
|
||||
|
||||
In order to access role information via the token you must include the right audience and the necessary role claims in the scope and/or select the required role settings in the ZITADEL management console before requesting the token.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ SCIM provisioning in ZITADEL is accomplished by authenticating a Service User wi
|
||||
|
||||
* Client Credentials Grant
|
||||
|
||||
4. Detailed instructions to authenticate the Service User can be found [here](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
|
||||
4. Detailed instructions to authenticate the Service User can be found [here](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).
|
||||
|
||||
## Step 2: Set Up SCIM in Okta
|
||||
|
||||
@@ -112,7 +112,7 @@ Review and adjust attribute mappings in Okta as needed:
|
||||
|
||||
* [ZITADEL: Creating Service Users](https://zitadel.com/docs/guides/manage/console/users-overview)
|
||||
|
||||
* [ZITADEL: Service User Authentication](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users)
|
||||
* [ZITADEL: Service User Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts)
|
||||
|
||||
* [ZITADEL SCIM 2.0 API Endpoints](https://zitadel.com/docs/apis/scim2)
|
||||
|
||||
|
||||
+5
-5
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Authenticate service users and client applications
|
||||
sidebar_label: Authenticate service users
|
||||
title: Authenticate service accounts and client applications
|
||||
sidebar_label: Authenticate service accounts
|
||||
---
|
||||
|
||||
import DocCardList from '@/components/docusaurus/doc-card-list';
|
||||
@@ -12,7 +12,7 @@ This guide explains ZITADEL service users and their role in facilitating secure
|
||||
Service users in ZITADEL represent **non-human entities** within your system.
|
||||
They are ideal for scenarios involving secure communication between applications, particularly when interacting with backend services or APIs.
|
||||
Service users in combination with [Manager](/concepts/structure/managers) permissions are used to access ZITADEL's APIs, for example, to manage user resources.
|
||||
Unlike regular human users, service users don't rely on traditional login methods (e.g., username/password) and require alternative authentication mechanisms.
|
||||
Unlike users, service accounts don't rely on traditional login methods (e.g., username/password) and require alternative authentication mechanisms.
|
||||
|
||||
## Benefits of using Service Users
|
||||
|
||||
@@ -84,7 +84,7 @@ This method is still available in ZITADEL but is generally considered less secur
|
||||
### Personal Access Tokens (PATs)
|
||||
|
||||
* **Ready-to-use tokens:** Generated for specific service users and can be directly included in the authorization header of API requests.
|
||||
* **Currently available only for machine users** (service users) and not regular human users.
|
||||
* **Currently available only for service accounts** and not users.
|
||||
|
||||
Follow our guide on using [personal access tokens](./personal-access-token) to get started authenticating service users and applications.
|
||||
|
||||
@@ -127,7 +127,7 @@ However, [client credentials authentication](./client-credentials) might be cons
|
||||
|
||||
## Further resources
|
||||
|
||||
* Read about the [different methods to authenticate service users](./authenticate-service-users)
|
||||
* Read about the [different methods to authenticate service users](./authenticate-service-accounts)
|
||||
* [Service User API reference](/reference/api/user)
|
||||
* [OIDC JWT with private key](/apis/openidoauth/authn-methods#jwt-with-private-key) authentication method reference
|
||||
* [Access ZITADEL APIs](../zitadel-apis/access-zitadel-apis)
|
||||
+3
-3
@@ -3,9 +3,9 @@ title: Configure client credential authentication for service users
|
||||
sidebar_label: Client credential authentication
|
||||
---
|
||||
|
||||
This guide demonstrates how developers can leverage Client Credential authentication to secure communication between [service users](/guides/manage/console/users-overview#service-users-machine-accounts) and client applications within ZITADEL.
|
||||
This guide demonstrates how developers can leverage Client Credential authentication to secure communication between [service users](/guides/manage/console/users-overview#service-accounts) and client applications within ZITADEL.
|
||||
|
||||
In ZITADEL, the Client Credentials Flow can be used for this [non-interactive authentication](./authenticate-service-users) as alternative to the [JWT profile authentication](./authenticate-service-users).
|
||||
In ZITADEL, the Client Credentials Flow can be used for this [non-interactive authentication](./authenticate-service-accounts) as alternative to the [JWT profile authentication](./authenticate-service-accounts).
|
||||
|
||||
## Steps to authenticate a Service User with client credentials
|
||||
|
||||
@@ -101,7 +101,7 @@ By following these steps and adhering to security best practices, you can effect
|
||||
|
||||
## Notes
|
||||
|
||||
* Read about the [different methods to authenticate service users](./authenticate-service-users)
|
||||
* Read about the [different methods to authenticate service users](./authenticate-service-accounts)
|
||||
* [Service User API reference](/reference/api/user)
|
||||
* [OIDC client secret basic](/apis/openidoauth/authn-methods#client-secret-basic) authentication method reference
|
||||
* [Access ZITADEL APIs](../zitadel-apis/access-zitadel-apis)
|
||||
+1
-1
@@ -6,7 +6,7 @@ sidebar_label: Personal access token authentication
|
||||
A Personal Access Token (PAT) is a ready to use token which can be used as _Authorization_ header.
|
||||
At the moment ZITADEL only allows PATs for machine accounts (service users).
|
||||
|
||||
It is an alternative to the [private key JWT](./private-key-jwt) and [client credentials](./client-credentials). Read more about the different [authentication methods for service users](./authenticate-service-users).
|
||||
It is an alternative to the [private key JWT](./private-key-jwt) and [client credentials](./client-credentials). Read more about the different [authentication methods for service users](./authenticate-service-accounts).
|
||||
|
||||
## Create a Service User with a PAT
|
||||
|
||||
+1
-1
@@ -7,7 +7,7 @@ This guide explains how developers can use private key JWT authentication to sec
|
||||
|
||||
In ZITADEL, the `urn:ietf:params:oauth:grant-type:jwt-bearer` (**"JWT bearer token with private key"**, [RFC7523](https://tools.ietf.org/html/rfc7523)) authorization grant type is used for non-interactive authentication.
|
||||
|
||||
Read more about the [different authentication methods for service users](./authenticate-service-users), including their benefits, drawbacks, and security considerations.
|
||||
Read more about the [different authentication methods for service users](./authenticate-service-accounts), including their benefits, drawbacks, and security considerations.
|
||||
|
||||
#### How private key JWT authentication works
|
||||
|
||||
@@ -27,7 +27,7 @@ If you have an API that behaves as an OAuth resource server that can be accessed
|
||||
|
||||
If there are client APIs or systems that need to access other protected APIs, these APIs or systems must be declared as [service users](/guides/manage/console/users-overview).
|
||||
A service user is not considered an application type in ZITADEL.
|
||||
Read the introduction on how to [authenticate service users](/guides/integrate/service-users/authenticate-service-users).
|
||||
Read the introduction on how to [authenticate service users](/guides/integrate/service-accounts/authenticate-service-accounts).
|
||||
|
||||
## Further references
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ import IntrospectionResponse from './_introspection-response.mdx';
|
||||
|
||||
This guide explains how to use ZITADEL's [Private Key JWT authentication method](/apis/openidoauth/authn-methods#jwt-with-private-key) to authenticate your application and call the token introspection endpoint. This is not about securing an API, but about allowing your backend to introspect access tokens in a secure way.
|
||||
|
||||
If you're looking to set up Private Key JWT authentication specifically for Service Users, see our dedicated guide [here](/guides/integrate/service-users/private-key-jwt).
|
||||
If you're looking to set up Private Key JWT authentication specifically for Service Users, see our dedicated guide [here](/guides/integrate/service-accounts/private-key-jwt).
|
||||
|
||||
## Register an Application & Generate a Key Pair
|
||||
|
||||
|
||||
@@ -27,9 +27,9 @@ For further details and in-depth exploration, you can refer to the [ZITADEL API
|
||||
|
||||
Accessing ZITADEL APIs, except for the Auth API and the System API, requires these basic steps:
|
||||
|
||||
1. **Create a service user**: A service user is a special type of account used to grant programmatic access to ZITADEL's functionalities. Unlike regular users who log in with a username and password, [service users rely on a more secure mechanism involving digital keys and tokens](../service-users/authenticate-service-users).
|
||||
1. **Create a service user**: A service user is a special type of account used to grant programmatic access to ZITADEL's functionalities. Unlike regular users who log in with a username and password, [service users rely on a more secure mechanism involving digital keys and tokens](../service-accounts/authenticate-service-accounts).
|
||||
2. **Give permission to access ZITADEL APIs**: Assign a Administrator role to the service user, giving it permission to make changes to certain resources in ZITADEL.
|
||||
3. **Authenticate the service user**: Like human users, service users must authenticate and request an OAuth token with the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to access ZITADEL APIs. [Service users can be authenticated](../service-users/authenticate-service-users) using private key JWT, client credentials, or personal access tokens.
|
||||
3. **Authenticate the service account**: Like users, service accounts must authenticate and request an OAuth token with the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to access ZITADEL APIs. [Service accounts can be authenticated](../service-accounts/authenticate-service-accounts) using private key JWT, client credentials, or personal access tokens.
|
||||
4. **Access ZITADEL APIs with the token**: The OAuth token must be included in the Authorization Header of calls to ZITADEL APIs.
|
||||
|
||||
### Accessing Auth API
|
||||
@@ -84,7 +84,7 @@ To be able to access the ZITADEL APIs your service user needs permissions to ZIT
|
||||
## 3. Authenticate service user and request token
|
||||
|
||||
Service users can be authenticated using private key JWT, client credentials, or personal access tokens.
|
||||
The [service user authentication](../service-users/authenticate-service-users) can be used to make machine-to-machine requests to any Resource Server (eg, a backend service / API) by requesting a token from the Authorization Server (ZITADEL) and sending the short-lived token (access token) in the Header of requests.
|
||||
The [service user authentication](../service-accounts/authenticate-service-accounts) can be used to make machine-to-machine requests to any Resource Server (eg, a backend service / API) by requesting a token from the Authorization Server (ZITADEL) and sending the short-lived token (access token) in the Header of requests.
|
||||
|
||||
This guide covers a specific case of service user authentication when requesting access to the [ZITADEL APIs](/apis/introduction).
|
||||
While PAT can be used directly to access the ZITADEL APIS, the more secure authentication methods private key JWT and client credentials must include the [reserved scope](/apis/openidoauth/scopes) `urn:zitadel:iam:org:project:id:zitadel:aud` when requesting an access from the token endpoint.
|
||||
@@ -95,7 +95,7 @@ The following sections will explain the more specific authentication to access t
|
||||
|
||||
### Authenticate with private key JWT
|
||||
|
||||
Follow the steps in this guide to [generate an key file](../service-users/private-key-jwt#2-register-a-private-key-for-your-service-user) and [create a JWT and sign with private key](../service-users/private-key-jwt#3-create-a-jwt-and-sign-it-with-your-private-key).
|
||||
Follow the steps in this guide to [generate an key file](../service-accounts/private-key-jwt#2-register-a-private-key-for-your-service-user) and [create a JWT and sign with private key](../service-accounts/private-key-jwt#3-create-a-jwt-and-sign-it-with-your-private-key).
|
||||
|
||||
With the encoded JWT (assertion) from the prior step, you will need to craft a POST request to ZITADEL's token endpoint.
|
||||
|
||||
@@ -232,4 +232,4 @@ curl --request GET \
|
||||
- [Example application in Go](./example-zitadel-api-with-go) to access ZITADEL APIs
|
||||
- [Example application in .NET](./example-zitadel-api-with-dot-net) to access ZITADEL APIs
|
||||
- Learn how to use the [Event API](./event-api) to retrieve your audit trail
|
||||
- Read about the [different methods to authenticate service users](../service-users/authenticate-service-users)
|
||||
- Read about the [different methods to authenticate service users](../service-accounts/authenticate-service-accounts)
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ All that is required, is a service account with an Org Owner (or another role, d
|
||||
However, we recommend you read the guide on [how to access ZITADEL API](/guides/integrate/zitadel-apis/access-zitadel-apis) and the associated guides for a basic knowledge of :
|
||||
|
||||
- [Recommended Authorization Flows](/guides/integrate/login/oidc/oauth-recommended-flows)
|
||||
- [Service Users](/guides/integrate/service-users/authenticate-service-users)
|
||||
- [Service Users](/guides/integrate/service-accounts/authenticate-service-accounts)
|
||||
|
||||
> Be sure to have a valid key JSON and that its service account is either ORG_OWNER or at least ORG_OWNER_VIEWER before you continue with this guide.
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ All that is required, is a service account with an Org Owner (or another role, d
|
||||
|
||||
However, we recommend you read the guide on [how to access ZITADEL API](/guides/integrate/zitadel-apis/access-zitadel-apis)) and the associated guides for a basic knowledge of :
|
||||
- [Recommended Authorization Flows](/guides/integrate/login/oidc/oauth-recommended-flows)
|
||||
- [Service Users](/guides/integrate/service-users/authenticate-service-users)
|
||||
- [Service Users](/guides/integrate/service-accounts/authenticate-service-accounts)
|
||||
|
||||
> Be sure to have a valid key JSON and that its service account is either ORG_OWNER or at least ORG_OWNER_VIEWER before you continue with this guide.
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ In this case please enable the Feature Flag "Use V2 Api in Management Console fo
|
||||
<Tab value="human_deprecated" label="Human User [deprecated]">
|
||||
<img src="/docs/img/guides/console/addhuman.png" width="680px" alt="Add Human" />
|
||||
|
||||
After a human user is created, by default, an initialization mail with a code is sent to the registered email. This code then has to be verified on first login.
|
||||
After a user is created, by default, an initialization mail with a code is sent to the registered email. This code then has to be verified on first login.
|
||||
If you want to omit this mail, you can check the **email verified** and **set initial password** toggle.
|
||||
If no password is set initially, the initialization mail prompting the user to set his password is sent.
|
||||
|
||||
|
||||
@@ -66,7 +66,7 @@ When no specific organization is selected (e.g., during an auth request or via [
|
||||
|
||||
## Usernames and Domains
|
||||
|
||||
Each organization has its own pool of users, covering both human and service users. How these users authenticate depends on your domain configuration.
|
||||
Each organization has its own pool of users, covering both users and service accounts. How these users authenticate depends on your domain configuration.
|
||||
|
||||
### Login Name Formats
|
||||
By default, if the setting **User Loginname must contain orgdomain** is **disabled**, usernames are unique across the entire instance.
|
||||
|
||||
@@ -8,22 +8,22 @@ import CreateUser from './_create-user.mdx';
|
||||
|
||||
## Overview
|
||||
|
||||
ZITADEL supports authentication and authorization for different user types. We mainly differentiate between **Human Users** (interactive) and **Service Users** (machine-to-machine).
|
||||
ZITADEL supports authentication and authorization for different user types. We mainly differentiate between **users** (interactive) and **Service Accounts** (machine-to-machine).
|
||||
|
||||
<img src="/docs/img/guides/console/usersmenu.png" width="420px" alt="User types" />
|
||||
|
||||
## Types of Users
|
||||
|
||||
### Human Users
|
||||
Human users represent actual people who log in via an interactive interface (e.g., a login page).
|
||||
### Users (Human)
|
||||
Users represent actual people who log in via an interactive interface (e.g., a login page).
|
||||
* **Profile:** Has an email address, password, and optional profile data (phone, nickname, gender, language).
|
||||
* **Authentication:** Can authenticate via password, multiple factors (MFA), or passwordless authentication (Passkeys).
|
||||
* **Flow:** The application redirects the user to ZITADEL, which handles the credentials and issues a token to the application.
|
||||
|
||||
Read more on how to [login users with ZITADEL](/guides/integrate/login/login-users).
|
||||
|
||||
### Service Users (Machine Accounts)
|
||||
Service users represent machines, backend services, or IoT devices requiring non-interactive access.
|
||||
### Service Accounts
|
||||
Service accounts represent machines, backend services, or IoT devices requiring non-interactive access.
|
||||
* **Profile:** Only has a name, description, and username.
|
||||
* **Authentication:** Authenticates via **JWT Profile** or **Personal Access Tokens (PAT)**. Both methods support expiration settings.
|
||||
* **Usage:** Primarily used to gain access to the ZITADEL Management API or to secure backend-to-backend communication.
|
||||
@@ -40,7 +40,7 @@ In a multi-tenancy architecture, users are typically isolated within [Organizati
|
||||
However, using [External User Grants](../../../concepts/features/external-user-grant), an organization can invite users from *another* organization to access their projects. These invited users are referred to as **External Users** within the context of the inviting organization.
|
||||
|
||||
### Managers
|
||||
Any user—whether Human or Service User—can be assigned an [Administrator Role](/concepts/structure/managers).
|
||||
Any user—whether User or Service Account—can be assigned an [Administrator Role](/concepts/structure/managers).
|
||||
A user with an administrator role is not just an end-user of your application but also has permissions to manage specific aspects of the ZITADEL instance, organization, or project (e.g., `ORG_OWNER`, `PROJECT_OWNER`).
|
||||
|
||||
## Considerations
|
||||
|
||||
@@ -12,14 +12,14 @@ ZITADEL differs two different types of users:
|
||||
|
||||
<img src="/docs/img/guides/console/usersmenu.png" width="420px" alt="User types" />
|
||||
|
||||
A human user has an email address and a password, and can additionally save information about phone, nickname, gender, language.
|
||||
A service user only has a name and a description aside his username.
|
||||
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 user can be authenticated with JWT profile or Personal Access Tokens. Both methods can specify an expiry.
|
||||
A human user can authenticate itself with his password, add multiple factors for additional security, and enable passkey authentication.
|
||||
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 users can also be ZITADEL managers is used to restrict access to specific projects or organizations.
|
||||
To get an understanding on how service users are used, take a look at our NextJS B2B Demo application.
|
||||
Service users are primarily used to gain access for a backend service or iot device. The fact that service accounts can also be ZITADEL managers 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
|
||||
|
||||
|
||||
@@ -221,7 +221,7 @@ Learn everything about how to build your own registration UI [here](/guides/inte
|
||||
The previous methods allowed you to retrieve metadata only for the `sub` in the access token.
|
||||
In case you want to get the metadata for another user, you need to use the management service.
|
||||
The user that calls the management service must have [manager permissions](/guides/manage/console/managers).
|
||||
A user can be either a human user or a service user.
|
||||
A user can be either a User (Human) or a Service Account.
|
||||
|
||||
You can get [metadata of a user filtered by your query](/apis/resources/mgmt/management-service-list-user-metadata) or [get a metadata object from a user by a specific key](/apis/resources/mgmt/management-service-get-user-metadata).
|
||||
The management service allows you to set and delete metadata, see the [API documentation for users](/reference/api/user).
|
||||
|
||||
@@ -14,7 +14,7 @@ It can be used to create, update, and delete ZITADEL resources, as well as to ma
|
||||
Make sure you create the following resources in ZITADEL and have [Terraform installed](https://learn.hashicorp.com/tutorials/terraform/install-cli):
|
||||
|
||||
- [A ZITADEL Instance](../start/quickstart)
|
||||
- [A service user](/guides/integrate/service-users/authenticate-service-users) with [enough authorization](/guides/manage/console/managers) to manage the desired resources
|
||||
- [A service user](/guides/integrate/service-accounts/authenticate-service-accounts) with [enough authorization](/guides/manage/console/managers) to manage the desired resources
|
||||
|
||||
## Manage ZITADEL resources through terraform
|
||||
|
||||
@@ -25,7 +25,7 @@ To provide a small guide to where to start:
|
||||
1. Create a folder where all the terraform files reside.
|
||||
2. Configure the provider to use the right domain, port and token, with for example a `main.tf`file [as shown in the example](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs).
|
||||
3. Add a `zitadel_org` resource to the `main.tf` file, to create and manage a new organization in the instance, [as shown in the example](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs/resources/org).
|
||||
4. Add any resources to the organization in the `main.tf` file, [as example a human user](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs/resources/human_user).
|
||||
4. Add any resources to the organization in the `main.tf` file, [as an example a user](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs/resources/human_user).
|
||||
5. (Optional) Use Terraform in the directory with the command `terraform plan`, to see which resources would be created and how.
|
||||
6. Apply the changes and start managing your resources with terraform with `terraform apply`.
|
||||
7. (Optional) Delete your created resources with `terraform destroy` to clean-up.
|
||||
|
||||
@@ -122,12 +122,12 @@ To call the ZITADEL Admin API, you need to authenticate using a **Service User**
|
||||
There are two recommended authentication methods:
|
||||
|
||||
- **Client Credentials Flow**
|
||||
[Learn how to authenticate with client credentials.](https://zitadel.com/docs/guides/integrate/service-users/client-credentials)
|
||||
[Learn how to authenticate with client credentials.](https://zitadel.com/docs/guides/integrate/service-accounts/client-credentials)
|
||||
|
||||
- **Personal Access Token (PAT)**
|
||||
[Learn how to create and use a PAT.](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users#personal-access-token)
|
||||
[Learn how to create and use a PAT.](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts#personal-access-token)
|
||||
|
||||
**Reference:** [Service Users & API Authentication](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users#authentication-methods)
|
||||
**Reference:** [Service Users & API Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts#authentication-methods)
|
||||
|
||||
### 5.2. Import Data with the ZITADEL API
|
||||
|
||||
|
||||
@@ -105,18 +105,18 @@ To call the ZITADEL Management API, you need to authenticate using a **Service U
|
||||
There are two recommended authentication methods:
|
||||
|
||||
* **Client Credentials Flow**
|
||||
[Learn how to authenticate with client credentials.](https://zitadel.com/docs/guides/integrate/service-users/client-credentials)
|
||||
[Learn how to authenticate with client credentials.](https://zitadel.com/docs/guides/integrate/service-accounts/client-credentials)
|
||||
|
||||
* **Personal Access Token (PAT)**
|
||||
[Learn how to create and use a PAT.](https://zitadel.com/docs/guides/integrate/service-users/personal-access-token)
|
||||
[Learn how to create and use a PAT.](https://zitadel.com/docs/guides/integrate/service-accounts/personal-access-token)
|
||||
|
||||
**Reference:** [Service Users & API Authentication](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users#authentication-methods)
|
||||
**Reference:** [Service Users & API Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts#authentication-methods)
|
||||
|
||||
---
|
||||
|
||||
### 5.2. Import Data with the ZITADEL API
|
||||
|
||||
Use your **access token** or **PAT** to authenticate, then call the [Management API – Human User Import](/reference/api/management/zitadel.management.v1.ManagementService.ImportHumanUser) endpoint.
|
||||
Use your **access token** or **PAT** to authenticate, then call the [Management API – User Import](/reference/api/management/zitadel.management.v1.ManagementService.ImportHumanUser) endpoint.
|
||||
|
||||
**Import Endpoint:**
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@ You need a PAT from a service user with IAM Owner permissions in both the source
|
||||
|
||||
1. Go to your default organization
|
||||
2. Create a service user "import_user" with Access Token Type "Bearer"
|
||||
3. Create a [personal access token](/guides/integrate/service-users/personal-access-token)
|
||||
3. Create a [personal access token](/guides/integrate/service-accounts/personal-access-token)
|
||||
4. Go to the Default settings
|
||||
5. Add the import_user as [manager](/guides/manage/console/managers) with the role "IAM Owner"
|
||||
|
||||
@@ -46,7 +46,7 @@ Save the PAT to the environment variable `PAT_EXPORT_TOKEN` and the source domai
|
||||
|
||||
1. Go to your default organization
|
||||
2. Create a service user "export_user" with Access Token Type "Bearer"
|
||||
3. Create a [personal access token](/guides/integrate/service-users/personal-access-token)
|
||||
3. Create a [personal access token](/guides/integrate/service-accounts/personal-access-token)
|
||||
4. Go to the Default settings
|
||||
5. Add the export_user as [manager](/guides/manage/console/managers) with the role "IAM Owner"
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ First, you need a user with manager permissions to change the project settings i
|
||||
This means either you add the manager to the organization or you use a manager on the instance level with "IAM-OWNER" permissions.
|
||||
After that create a Personal Access Token (PAT) for the manager.
|
||||
|
||||
More detailed information about creating a PAT and administrator roles you can find [here](/guides/integrate/service-users/personal-access-token)
|
||||
More detailed information about creating a PAT and administrator roles you can find [here](/guides/integrate/service-accounts/personal-access-token)
|
||||
|
||||
Then you have to send the following request:
|
||||
```bash
|
||||
|
||||
@@ -407,7 +407,7 @@ You’ve successfully integrated ZITADEL into an application.
|
||||
<Callout type="warn" title="Prevent Misconfiguration Lockouts">
|
||||
Login policy misconfigurations that occur during the testing phase can easily lead to a [lockout](/legal/policies/account-lockout-policy). To ensure you don't lose access to your instance:
|
||||
|
||||
1. **Generate a backup PAT:** Create a [Service User Personal Access Token](/guides/integrate/service-users/personal-access-token) with the [`IAM_OWNER`](/guides/manage/console/managers) role to revert any login UI misconfigurations using the API.
|
||||
1. **Generate a backup PAT:** Create a [Service User Personal Access Token](/guides/integrate/service-accounts/personal-access-token) with the [`IAM_OWNER`](/guides/manage/console/managers) role to revert any login UI misconfigurations using the API.
|
||||
2. **Add a second Instance Manager:** Always designate at least one [**second instance manager**](/guides/manage/console/managers).
|
||||
|
||||
</Callout>
|
||||
|
||||
@@ -27,6 +27,6 @@ This strategic versioning will ensure a more consistent and intuitive developmen
|
||||
This SDK provides a convenient client for interacting with the ZITADEL APIs, simplifying how you manage resources within your instance.
|
||||
|
||||
Currently, the client is tailored for machine-to-machine communication, enabling machine users to authenticate and manage ZITADEL resources programmatically.
|
||||
Please note that this initial version is focused on API calls for automated tasks and does not yet include support for human user authentication flows like OAuth or OIDC.
|
||||
Please note that this initial version is focused on API calls for automated tasks and does not yet include support for user authentication flows like OAuth or OIDC.
|
||||
</details>
|
||||
</details>
|
||||
|
||||
@@ -162,7 +162,7 @@ class Demo {
|
||||
|
||||
Choose the authentication method that best suits your needs based on your
|
||||
environment and security requirements. For more details, please refer to the
|
||||
[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
|
||||
[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).
|
||||
|
||||
### Versioning
|
||||
|
||||
|
||||
@@ -193,7 +193,7 @@ try {
|
||||
|
||||
Choose the authentication method that best suits your needs based on your
|
||||
environment and security requirements. For more details, please refer to the
|
||||
[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
|
||||
[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).
|
||||
|
||||
### Versioning
|
||||
|
||||
|
||||
@@ -178,7 +178,7 @@ try {
|
||||
|
||||
Choose the authentication method that best suits your needs based on your
|
||||
environment and security requirements. For more details, please refer to the
|
||||
[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
|
||||
[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).
|
||||
|
||||
### Versioning
|
||||
|
||||
|
||||
@@ -182,7 +182,7 @@ except ApiError as e:
|
||||
|
||||
Choose the authentication method that best suits your needs based on your
|
||||
environment and security requirements. For more details, please refer to the
|
||||
[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
|
||||
[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).
|
||||
|
||||
### Versioning
|
||||
|
||||
|
||||
@@ -172,7 +172,7 @@ end
|
||||
|
||||
Choose the authentication method that best suits your needs based on your
|
||||
environment and security requirements. For more details, please refer to the
|
||||
[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users).
|
||||
[Zitadel documentation on authenticating service users](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts).
|
||||
|
||||
### Debugging
|
||||
|
||||
|
||||
@@ -95,7 +95,7 @@ The following table describes the milestones that are sent to the endpoints:
|
||||
| Trigger | Description |
|
||||
|-----------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| A virtual instance is created. | This data point is also sent when the first instance is automatically created during the ZITADEL binaries setup phase in a self-hosting scenario. |
|
||||
| An authentication succeeded for the first time on an instance. | This is the first authentication with the instances automatically created admin user during the instance setup, which can be a human or a machine. |
|
||||
| An authentication succeeded for the first time on an instance. | This is the first authentication with the instances automatically created admin user during the instance setup, which can be a user or a service account. |
|
||||
| A project is created for the first time in a virtual instance. | The ZITADEL project that is automatically created during the instance setup is omitted. |
|
||||
| An application is created for the first time in a virtual instance. | The applications in the ZITADEL project that are automatically created during the instance setup are omitted. |
|
||||
| An authentication succeeded for the first time in a virtual instances application. | This is the first authentication using a ZITADEL application that is not created during the instance setup phase. |
|
||||
|
||||
@@ -185,10 +185,10 @@ export const guidesSidebar: readonly SidebarItem[] = [
|
||||
type: "category",
|
||||
label: "Machine-to-Machine (M2M)",
|
||||
items: [
|
||||
"guides/integrate/service-users/authenticate-service-users",
|
||||
"guides/integrate/service-users/private-key-jwt",
|
||||
"guides/integrate/service-users/client-credentials",
|
||||
"guides/integrate/service-users/personal-access-token",
|
||||
"guides/integrate/service-accounts/authenticate-service-accounts",
|
||||
"guides/integrate/service-accounts/private-key-jwt",
|
||||
"guides/integrate/service-accounts/client-credentials",
|
||||
"guides/integrate/service-accounts/personal-access-token",
|
||||
],
|
||||
},
|
||||
],
|
||||
|
||||
Reference in New Issue
Block a user