diff --git a/apps/docs/content/apis/introduction.mdx b/apps/docs/content/apis/introduction.mdx index c16d4cd03..112ef74fb 100644 --- a/apps/docs/content/apis/introduction.mdx +++ b/apps/docs/content/apis/introduction.mdx @@ -25,10 +25,10 @@ Additionally, you can use the [session API](/reference/api/session) to authentic ### Authenticate service accounts -Service users allow for machine-to-machine (M2M) communication. +Service accounts allow for machine-to-machine (M2M) communication. 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. +Accessing the ZITADEL APIs through a service account 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. ### OpenID Connect & OAuth diff --git a/apps/docs/content/apis/migration_v1_to_v2.mdx b/apps/docs/content/apis/migration_v1_to_v2.mdx index 522658c4a..61ed97fdb 100644 --- a/apps/docs/content/apis/migration_v1_to_v2.mdx +++ b/apps/docs/content/apis/migration_v1_to_v2.mdx @@ -98,7 +98,7 @@ 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 User (Human) or machine users. + - 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 service accounts. - 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. diff --git a/apps/docs/content/apis/openidoauth/endpoints.mdx b/apps/docs/content/apis/openidoauth/endpoints.mdx index 883107731..8b0e1a8f5 100644 --- a/apps/docs/content/apis/openidoauth/endpoints.mdx +++ b/apps/docs/content/apis/openidoauth/endpoints.mdx @@ -270,7 +270,7 @@ curl --request POST \ | ------------ | ------------------------------------------------------------------------------------- | | access_token | An `access_token` as JWT or opaque token | | expires_in | Number of second until the expiration of the `access_token` | -| id_token | An `id_token` of the authorized service user | +| id_token | An `id_token` of the authorized service account | | scope | Scopes of the `access_token`. These might differ from the provided `scope` parameter. | | token_type | Type of the `access_token`. Value is always `Bearer` | diff --git a/apps/docs/content/apis/openidoauth/grant-types.mdx b/apps/docs/content/apis/openidoauth/grant-types.mdx index 7b7ed87e4..a354167da 100644 --- a/apps/docs/content/apis/openidoauth/grant-types.mdx +++ b/apps/docs/content/apis/openidoauth/grant-types.mdx @@ -44,9 +44,9 @@ For a list of supported or unsupported `Grant Types` please have a look at the t ### Using JWTs as Authorization Grants -Our service user work with the JWT profile to authenticate them against ZITADEL. +Our service account works with the JWT profile to authenticate them against ZITADEL. -1. Create or use an existing service user +1. Create or use an existing service account 2. Create a new key and download it 3. Generate a JWT with the structure below and sign it with the downloaded key 4. Send the JWT Base64 encoded to ZITADEL's token endpoint @@ -61,7 +61,7 @@ Key JSON | type | `"serviceaccount"` | The type of account, right now only serviceaccount is valid | | keyId | `"81693565968772648"` | This is unique ID of the key | | key | `"-----BEGIN RSA PRIVATE KEY-----...-----END RSA PRIVATE KEY-----"` | The private key generated by ZITADEL, this can not be regenerated! | -| userId | `78366401571647008` | The service users ID, this is the same as the subject from tokens | +| userId | `78366401571647008` | The service accounts ID, this is the same as the subject from tokens | ```json { @@ -82,7 +82,7 @@ JWT | exp | `1605183582` | Unix timestamp of the expiry | | iat | `1605179982` | Unix timestamp of the creation singing time of the JWT, MUST NOT be older than 1h | | iss | `"77479219772321307"` | String which represents the requesting party (owner of the key), normally the `userId` from the json key file | -| sub | `"77479219772321307"` | The subject ID of the service user, normally the `userId` from the json key file | +| sub | `"77479219772321307"` | The subject ID of the service account, normally the `userId` from the json key file | ```json { diff --git a/apps/docs/content/apis/scim2.mdx b/apps/docs/content/apis/scim2.mdx index de062b767..d87a96080 100644 --- a/apps/docs/content/apis/scim2.mdx +++ b/apps/docs/content/apis/scim2.mdx @@ -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-accounts/authenticate-service-accounts). +For detailed instructions on authenticating with the SCIM interface, refer to the [Authenticate Service Accounts Guide](/guides/integrate/service-accounts/authenticate-service-accounts). ## Query diff --git a/apps/docs/content/concepts/features/audit-trail.mdx b/apps/docs/content/concepts/features/audit-trail.mdx index fbce7b1ab..0eccf621a 100644 --- a/apps/docs/content/concepts/features/audit-trail.mdx +++ b/apps/docs/content/concepts/features/audit-trail.mdx @@ -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-accounts/authenticate-service-accounts) account, allowing you to integrate the events with your own business logic. +Access to the API is possible with a [Service Account](/guides/integrate/service-accounts/authenticate-service-accounts), allowing you to integrate the events with your own business logic. ## Using logs in external systems diff --git a/apps/docs/content/concepts/features/selfservice.mdx b/apps/docs/content/concepts/features/selfservice.mdx index 8a4cc294f..c14f16e61 100644 --- a/apps/docs/content/concepts/features/selfservice.mdx +++ b/apps/docs/content/concepts/features/selfservice.mdx @@ -67,8 +67,8 @@ 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-accounts/authenticate-service-accounts) and recommended [OpenID Connect Flows](/guides/integrate/login/oidc/oauth-recommended-flows#different-client-profiles). +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](/guides/integrate/service-accounts/authenticate-service-accounts) and recommended [OpenID Connect Flows](/guides/integrate/login/oidc/oauth-recommended-flows#different-client-profiles). ## Logout @@ -136,7 +136,7 @@ Thus, we will explain service for two of the most common scenarios in ZITADEL: - `Administrators in delegation`: Granting administrative permissions to a user from a different organization where the organizations depend on each other A list of [Administrator Roles](../../guides/manage/console/administrators#roles) is available with a description of permissions. -Administrators can be assigned to both human users and service users, e.g., for managing certain tasks programmatically. +Administrators can be assigned to both human users and service accounts, e.g., for managing certain tasks programmatically. ### Administrators in isolation diff --git a/apps/docs/content/concepts/structure/users.mdx b/apps/docs/content/concepts/structure/users.mdx index 646534f5b..3caf707a3 100644 --- a/apps/docs/content/concepts/structure/users.mdx +++ b/apps/docs/content/concepts/structure/users.mdx @@ -7,7 +7,7 @@ sidebar_label: Users ZITADEL supports authentication and authorization for different user types. We can mainly differentiate between Users and Service Accounts. -We typically call human users simply "Users" and machine users "Service Users". +Users are accounts operated/used by a human, while service accounts are those operated/used by an application/third-party software. ### Users @@ -17,10 +17,10 @@ ZITADEL handles the authentication and provides the application with a token tha Read more on how to [login users with ZITADEL](/guides/integrate/login/login-users). -### Service users +### Service accounts -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. +Service accounts 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 Account to access the Management API. The main difference between users and service accounts is the type of credentials that can be used for authentication: users typically logon via a login prompt, but service accounts require a non-interactive logon process. Learn how to [use service accounts](/guides/integrate/service-accounts/authenticate-service-accounts) with ZITADEL. diff --git a/apps/docs/content/examples/imports/_serviceaccount_jwt.mdx b/apps/docs/content/examples/imports/_serviceaccount_jwt.mdx new file mode 100644 index 000000000..32ea8955d --- /dev/null +++ b/apps/docs/content/examples/imports/_serviceaccount_jwt.mdx @@ -0,0 +1,42 @@ +1. Go to the **Users** tab in your organization as shown below and click on the **Service Accounts** tab. + +![](../../../public/img/examples/secure-api/service-account-jwt/1.png) + +2. To add a service account, click on the **New** button. + +![](../../../public/img/examples/secure-api/service-account-jwt/2.png) + +3. Next, add the details of the service account and select either **Bearer** or **JWT** for **Access Token Type** and click on **Create**. For this example, we will select **JWT**. + +![](../../../public/img/examples/secure-api/service-account-jwt/3.png) + +4. Now you will see the saved details. + +![](../../../public/img/examples/secure-api/service-account-jwt/4.png) + +5. Next, we need to generate a private-public key pair in ZITADEL and you must get the private key to sign your JWT. Go to **Keys** and click on **New**. + +![](../../../public/img/examples/secure-api/service-account-jwt/5.png) + +6. Select type **JSON** and click **Add**. + +![](../../../public/img/examples/secure-api/service-account-jwt/6.png) + +7. Download the key by clicking **Download**. After the download, click **Close**. + +![](../../../public/img/examples/secure-api/service-account-jwt/7.png) + +8. You will see the following screen afterward. + +![](../../../public/img/examples/secure-api/service-account-jwt/8.png) + +9. The downloaded key will be of the following format: + +``` +{ + "type":"serviceaccount", + "keyId":"", + "key":"-----BEGIN RSA PRIVATE KEY-----\n\n-----END RSA PRIVATE KEY-----\n", + "userId":"" +} +``` diff --git a/apps/docs/content/examples/imports/_serviceaccount_role.mdx b/apps/docs/content/examples/imports/_serviceaccount_role.mdx new file mode 100644 index 000000000..7c863926f --- /dev/null +++ b/apps/docs/content/examples/imports/_serviceaccount_role.mdx @@ -0,0 +1,36 @@ +In order to access this route, you must create the role `read:messages` in your ZITADEL project and also create an authorization for the service account you created by adding the role to the user. Follow these steps to do so: + +1. Go to your project and select **Roles**. Click **New**. + +![](../../../public/img/examples/secure-api/service-account-jwt/scopes/1.png) + +2. Add the `read:messages` role as shown below and click **Save**. + +![](../../../public/img/examples/secure-api/service-account-jwt/scopes/2.png) + +3. You will see the created role listed. + +![](../../../public/img/examples/secure-api/service-account-jwt/scopes/3.png) + +4. To assign this role to a user, click on **Authorizations**. + +![](../../../public/img/examples/secure-api/service-account-jwt/scopes/4.png) + +5. Select the user you want to assign the role to. + +![](../../../public/img/examples/secure-api/service-account-jwt/scopes/5.png) + +6. Select the project where this authorization is applicable. + +![](../../../public/img/examples/secure-api/service-account-jwt/scopes/6.png) +7. Click **Continue**. + +![](../../../public/img/examples/secure-api/service-account-jwt/scopes/7.png) + +8. Select the role **read:messages** and click **Save**. + +![](../../../public/img/examples/secure-api/service-account-jwt/scopes/8.png) + +9. You will now see the service account has been assigned the role **read:messages**. + +![](../../../public/img/examples/secure-api/service-account-jwt/scopes/9.png) diff --git a/apps/docs/content/examples/imports/_serviceuser_jwt.mdx b/apps/docs/content/examples/imports/_serviceuser_jwt.mdx deleted file mode 100644 index 8eece307f..000000000 --- a/apps/docs/content/examples/imports/_serviceuser_jwt.mdx +++ /dev/null @@ -1,42 +0,0 @@ -1. Go to the **Users** tab in your organization as shown below and click on the **Service Users** tab. - -![](../../../public/img/examples/secure-api/service-user-jwt/1.png) - -2. To add a service user, click on the **New** button. - -![](../../../public/img/examples/secure-api/service-user-jwt/2.png) - -3. Next, add the details of the service user and select either **Bearer** or **JWT** for **Access Token Type** and click on **Create**. For this example, we will select **JWT**. - -![](../../../public/img/examples/secure-api/service-user-jwt/3.png) - -4. Now you will see the saved details. - -![](../../../public/img/examples/secure-api/service-user-jwt/4.png) - -5. Next, we need to generate a private-public key pair in ZITADEL and you must get the private key to sign your JWT. Go to **Keys** and click on **New**. - -![](../../../public/img/examples/secure-api/service-user-jwt/5.png) - -6. Select type **JSON** and click **Add**. - -![](../../../public/img/examples/secure-api/service-user-jwt/6.png) - -7. Download the key by clicking **Download**. After the download, click **Close**. - -![](../../../public/img/examples/secure-api/service-user-jwt/7.png) - -8. You will see the following screen afterward. - -![](../../../public/img/examples/secure-api/service-user-jwt/8.png) - -9. The downloaded key will be of the following format: - -``` -{ - "type":"serviceaccount", - "keyId":"", - "key":"-----BEGIN RSA PRIVATE KEY-----\n\n-----END RSA PRIVATE KEY-----\n", - "userId":"" -} -``` diff --git a/apps/docs/content/examples/imports/_serviceuser_role.mdx b/apps/docs/content/examples/imports/_serviceuser_role.mdx deleted file mode 100644 index 0a0a9614e..000000000 --- a/apps/docs/content/examples/imports/_serviceuser_role.mdx +++ /dev/null @@ -1,36 +0,0 @@ -In order to access this route, you must create the role `read:messages` in your ZITADEL project and also create an authorization for the service user you created by adding the role to the user. Follow these steps to do so: - -1. Go to your project and select **Roles**. Click **New**. - -![](../../../public/img/examples/secure-api/service-user-jwt/scopes/1.png) - -2. Add the `read:messages` role as shown below and click **Save**. - -![](../../../public/img/examples/secure-api/service-user-jwt/scopes/2.png) - -3. You will see the created role listed. - -![](../../../public/img/examples/secure-api/service-user-jwt/scopes/3.png) - -4. To assign this role to a user, click on **Authorizations**. - -![](../../../public/img/examples/secure-api/service-user-jwt/scopes/4.png) - -5. Select the user you want to assign the role to. - -![](../../../public/img/examples/secure-api/service-user-jwt/scopes/5.png) - -6. Select the project where this authorization is applicable. - -![](../../../public/img/examples/secure-api/service-user-jwt/scopes/6.png) -7. Click **Continue**. - -![](../../../public/img/examples/secure-api/service-user-jwt/scopes/7.png) - -8. Select the role **read:messages** and click **Save**. - -![](../../../public/img/examples/secure-api/service-user-jwt/scopes/8.png) - -9. You will now see the service user has been assigned the role **read:messages**. - -![](../../../public/img/examples/secure-api/service-user-jwt/scopes/9.png) diff --git a/apps/docs/content/examples/login/nextjs-b2b.mdx b/apps/docs/content/examples/login/nextjs-b2b.mdx index ed04e1a2d..8922b2d23 100644 --- a/apps/docs/content/examples/login/nextjs-b2b.mdx +++ b/apps/docs/content/examples/login/nextjs-b2b.mdx @@ -59,20 +59,20 @@ To set up the needed roles for your project, navigate to your `Portal` project, Now in the `General` section of the Portal project, make sure to enable `Assert Roles on Authentication`. This makes sure that roles, which is used by the application to enable UI components, are set in your OIDC ID Token. -### Service User +### Service Account -To make the application work you need a service user which loads granted-projects and user-grants for you. -In the B2B-Demo organization, navigate to `Users` in navigation of Management Console, click on `Service Users` and create a new user. +To make the application work you need a service account which loads granted-projects and user-grants for you. +In the B2B-Demo organization, navigate to `Users` in navigation of Management Console, click on `Service Accounts` and create a new user. Let's set its username to `nextjs` and its name to `NextJS`. Then press `create`. On the detail page of that user, navigate to "Personal Access Tokens" and add a new entry, set an optional expiration date. Copy the generated Token as you will need this in your environment configuration file later. -Go back to the `Portal` project and add the Service User as Manager (top right). +Go back to the `Portal` project and add the Service Account as Manager (top right). Make sure to select `Project Owner Viewer` as the management role. -To show granted projects, go to the `Demo-Vendor` organization and add the Service User as `Org Project Permission Editor` Manager. +To show granted projects, go to the `Demo-Vendor` organization and add the Service Account as `Org Project Permission Editor` Manager. ## Configuration @@ -104,7 +104,7 @@ Replace the values as follows `ZITADEL_CLIENT_ID`: Having the project `Portal` selected, click on the Application `portal-web`. `${CLIENT_ID}` is displayed as a field in the OIDC configuration, labeled "Client ID" and has the format `12345678@portal`. -`SERVICE_ACCOUNT_ACCESS_TOKEN`: Set up a service user, add a Personal Access Token and copy the secret here (see below). +`SERVICE_ACCOUNT_ACCESS_TOKEN`: Set up a service account, add a Personal Access Token and copy the secret here (see below). ## Install and Run diff --git a/apps/docs/content/examples/secure-api/go.mdx b/apps/docs/content/examples/secure-api/go.mdx index cfda95fe4..9a50c26f8 100644 --- a/apps/docs/content/examples/secure-api/go.mdx +++ b/apps/docs/content/examples/secure-api/go.mdx @@ -17,7 +17,7 @@ At the end of the guide you should have an API with a protected endpoint. ## Prerequisites This will handle the OAuth 2.0 introspection request including authentication using JWT with Private Key using our [Go SDK](https://github.com/zitadel/zitadel-go). -All that is required, is to create your API, create a private key and a personal access token for a service user. +All that is required, is to create your API, create a private key and a personal access token for a service account. ### Set up application and obtain keys @@ -54,15 +54,15 @@ And make sure to download it, as you won't be able to retrieve it again. Now we need to create a *Personal Access Token* to authenticate the application requests. -On the user view, switch to *Service Users* and create a new one. +On the user view, switch to *Service Accounts* and create a new one. ![](../../../public/img/go/api-service_user_panel.png) -Give the service user a name and a username. Select `Bearer` as *Access Token Type*. +Give the service account a name and a username. Select `Bearer` as *Access Token Type*. ![](../../../public/img/go/api-create_service_user.png) -### Create service user and personal access token (PAT) +### Create service account and personal access token (PAT) Once done, from the left panel of the user management, click on Personal Access Token and create a new one. diff --git a/apps/docs/content/examples/secure-api/pylon.mdx b/apps/docs/content/examples/secure-api/pylon.mdx index 301dc765f..3d225aeed 100644 --- a/apps/docs/content/examples/secure-api/pylon.mdx +++ b/apps/docs/content/examples/secure-api/pylon.mdx @@ -4,8 +4,8 @@ sidebar_label: Pylon --- import AppJWT from "../imports/_app_jwt.mdx"; -import ServiceuserJWT from "../imports/_serviceuser_jwt.mdx"; -import ServiceuserRole from "../imports/_serviceuser_role.mdx"; +import ServiceAccountJWT from "../imports/_serviceaccount_jwt.mdx"; +import ServiceAccountRole from "../imports/_serviceaccount_role.mdx"; This integration guide demonstrates the recommended way to incorporate ZITADEL into your [Pylon](https://pylon.cronit.io) service. It explains how to check the token validity in the API and how to check for permissions. @@ -20,13 +20,13 @@ Before we can start building our application, we have to do a few configuration -### Create Serviceuser +### Create Service Account - + -### Give Serviceuser an authorization +### Give Service Account an authorization - + ### Prerequisites @@ -36,9 +36,9 @@ At the end you should have the following for the API: - `.json`-key-file for the API, from the application - ID of the project -And the following from the Serviceuser: +And the following from the Service Account: -- `.json`-key-file from the serviceuser +- `.json`-key-file from the service account ## Setup new Pylon service @@ -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. -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). +You can also create a PAT for the service account and use it to test the API. For this, follow [this guide](/guides/integrate/service-accounts/personal-access-token#create-a-service-account-with-a-pat). Optionally set the token as an environment variable: diff --git a/apps/docs/content/examples/secure-api/python-django.mdx b/apps/docs/content/examples/secure-api/python-django.mdx index 903c6bd30..8d4602bf9 100644 --- a/apps/docs/content/examples/secure-api/python-django.mdx +++ b/apps/docs/content/examples/secure-api/python-django.mdx @@ -4,8 +4,8 @@ sidebar_label: Django --- import AppJWT from '../imports/_app_jwt.mdx'; -import ServiceuserJWT from '../imports/_serviceuser_jwt.mdx'; -import ServiceuserRole from '../imports/_serviceuser_role.mdx'; +import ServiceAccountJWT from '../imports/_serviceaccount_jwt.mdx'; +import ServiceAccountRole from '../imports/_serviceaccount_role.mdx'; import SetupPython from '../imports/_setup_python.mdx'; This integration guide demonstrates the recommended way to incorporate ZITADEL into your Django Python application. @@ -25,13 +25,13 @@ Before we can start building our application, we have to do a few configuration -### Create Serviceuser +### Create Service Account - + -### Give Serviceuser an authorization +### Give Service Account an authorization - + ### Prerequisites @@ -42,8 +42,8 @@ At the end you should have the following for the API: - `.json`-key-file for the API, from the application - ID of the project -And the following from the Serviceuser: -- `.json`-key-file from the serviceuser +And the following from the Service Account: +- `.json`-key-file from the service account ## Setup new Django application diff --git a/apps/docs/content/examples/secure-api/python-flask.mdx b/apps/docs/content/examples/secure-api/python-flask.mdx index cf637c689..77e2ce433 100644 --- a/apps/docs/content/examples/secure-api/python-flask.mdx +++ b/apps/docs/content/examples/secure-api/python-flask.mdx @@ -182,13 +182,13 @@ CLIENT_ID = "197....@projectname" CLIENT_SECRET = "NVAp70IqiGmJldbS...." ``` -### ZITADEL configuration to create a service user +### ZITADEL configuration to create a service account ![](../../../public/img/python-flask/3.png) -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). +1. Create a service account and a Personal Access Token (PAT) for that user by following [this guide](/guides/integrate/service-accounts/personal-access-token#create-a-service-account-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. +3. Next, create an authorization for the service account 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. ### Run the API @@ -222,7 +222,7 @@ curl --request GET \ You should get a response with Status Code 401 and an error message. -Now let's add an authorization header to your request. Save the personal access token for your service user to a variable by running the following command. Replace the value with the PAT you obtained earlier. +Now let's add an authorization header to your request. Save the personal access token for your service account to a variable by running the following command. Replace the value with the PAT you obtained earlier. `PAT=nr9vnUTkQkn4rxWk...` @@ -252,4 +252,4 @@ You should get a response with Status Code 200 and the following message. `{"message":"Private, scoped route - You need to be authenticated and have the role read:messages to see this."}` -You can remove the role from the service user in ZITADEL and try again. You should then get a Status Code 403, Forbidden error. +You can remove the role from the service account in ZITADEL and try again. You should then get a Status Code 403, Forbidden error. diff --git a/apps/docs/content/guides/integrate/login-ui/login-app.mdx b/apps/docs/content/guides/integrate/login-ui/login-app.mdx index dc60e150f..5538b5124 100644 --- a/apps/docs/content/guides/integrate/login-ui/login-app.mdx +++ b/apps/docs/content/guides/integrate/login-ui/login-app.mdx @@ -23,7 +23,7 @@ Its set of features will increase with time and its progress will be tracked [he The new Login app consists of a confidential (backend) part and a browser (client side) part. In addition to that, the OIDC specification builds upon a proxy which is set up in the Next.js middleware. It rewrites requests of the paths `/.well-known/:path*`, `/oauth/:path*`, `/oidc/:path*` to ZITADEL. -The backend side of the application is authorized using a machine user's personal access token. +The backend side of the application is authorized using a service account's personal access token. This token is used to fetch policies and settings from your instances or organization which define how users are authenticated and how the Login app is displayed. The frontend side of the application communicates to the backend side by using a cookie which is set by the server. @@ -137,7 +137,7 @@ You can review an example implementation of a middleware [here](https://github.c Deploy with Vercel -To deploy your own version on Vercel, navigate to your instance and create a service user. +To deploy your own version on Vercel, navigate to your instance and create a service account. Create a personal access token (PAT) for the user and copy and set it as `ZITADEL_SERVICE_USER_TOKEN`, then navigate to Default settings and make sure it gets `IAM_LOGIN_CLIENT` permissions. Finally set your instance url as `ZITADEL_API_URL`. Make sure to set it without trailing slash. Also ensure your login domain is registered on your instance by adding it as a [Trusted Domain](/apis/resources/admin/admin-service-add-instance-trusted-domain). diff --git a/apps/docs/content/guides/integrate/login/_prevent-lockout.mdx b/apps/docs/content/guides/integrate/login/_prevent-lockout.mdx index 5bf714c9d..2264d745b 100644 --- a/apps/docs/content/guides/integrate/login/_prevent-lockout.mdx +++ b/apps/docs/content/guides/integrate/login/_prevent-lockout.mdx @@ -1,4 +1,4 @@ - Before you change your Zitadel configuration, we highly recommend you to create a service user with a personal access token (PAT) and the IAM_OWNER role. + Before you change your Zitadel configuration, we highly recommend you to create a service account with a personal access token (PAT) and the IAM_OWNER role. In case something breaks, you can use this PAT to revert your changes or fix the configuration so you can use a login UI again. diff --git a/apps/docs/content/guides/integrate/login/hosted-login.mdx b/apps/docs/content/guides/integrate/login/hosted-login.mdx index 70685f391..b6324c802 100644 --- a/apps/docs/content/guides/integrate/login/hosted-login.mdx +++ b/apps/docs/content/guides/integrate/login/hosted-login.mdx @@ -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-accounts/personal-access-token#create-a-service-user-with-a-pat) with a PAT in your instance + 1. [Create a service account](/guides/integrate/service-accounts/personal-access-token#create-a-service-account-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 Administrator Guide](/guides/manage/console/administrators) 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) diff --git a/apps/docs/content/guides/integrate/retrieve-user-roles.mdx b/apps/docs/content/guides/integrate/retrieve-user-roles.mdx index 74db240e2..d68c9a0ff 100644 --- a/apps/docs/content/guides/integrate/retrieve-user-roles.mdx +++ b/apps/docs/content/guides/integrate/retrieve-user-roles.mdx @@ -215,7 +215,7 @@ https://github.com/zitadel/actions/blob/main/examples/custom_roles.js Now we will use the auth API to retrieve roles from a logged in user using the user’s token The base URL is: **https://`${CUSTOM_DOMAIN}`/auth/v1** -Let’s start with a user who has multiple roles in different organizations in a multi-tenanted set up. You can use the logged in user’s token or the machine user’s token to retrieve the authorizations using the [APIs listed under user authorizations/grants in the auth API](/reference/api/authorization). +Let’s start with a user who has multiple roles in different organizations in a multi-tenanted set up. You can use the logged in user’s token or the service account’s token to retrieve the authorizations using the [APIs listed under user authorizations/grants in the auth API](/reference/api/authorization). **Scope used:** `openid urn:zitadel:iam:org:project:id:zitadel:aud` diff --git a/apps/docs/content/guides/integrate/scim-okta-guide.mdx b/apps/docs/content/guides/integrate/scim-okta-guide.mdx index 2dd7d2e3f..1e942c5c2 100644 --- a/apps/docs/content/guides/integrate/scim-okta-guide.mdx +++ b/apps/docs/content/guides/integrate/scim-okta-guide.mdx @@ -14,15 +14,15 @@ This guide provides step-by-step instructions to configure SCIM provisioning fro ## Step 1: Set Up SCIM Provisioning in ZITADEL -SCIM provisioning in ZITADEL is accomplished by authenticating a Service User with appropriate permissions. +SCIM provisioning in ZITADEL is accomplished by authenticating a Service Account with appropriate permissions. -1. **Create a Service User**: +1. **Create a Service Account**: - * Follow [this guide](https://zitadel.com/docs/guides/manage/console/users-overview) to create a Service User within your ZITADEL Organization. + * Follow [this guide](https://zitadel.com/docs/guides/manage/console/users-overview) to create a Service Account within your ZITADEL Organization. 2. **Assign the Role**: - * Grant the Service User the **Org User Manager** role. No higher managerial role is required. + * Grant the Service Account the **Org User Manager** role. No higher managerial role is required. 3. **Choose an Authentication Method**: @@ -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-accounts/authenticate-service-accounts). +4. Detailed instructions to authenticate the Service Account can be found [here](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts). ## Step 2: Set Up SCIM in Okta @@ -110,9 +110,9 @@ Review and adjust attribute mappings in Okta as needed: * [Authenticate users with SAML](https://zitadel.com/docs/guides/integrate/login/saml) -* [ZITADEL: Creating Service Users](https://zitadel.com/docs/guides/manage/console/users-overview) +* [ZITADEL: Creating Service Accounts](https://zitadel.com/docs/guides/manage/console/users-overview) -* [ZITADEL: Service User Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts) +* [ZITADEL: Service Account Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts) * [ZITADEL SCIM 2.0 API Endpoints](https://zitadel.com/docs/apis/scim2) diff --git a/apps/docs/content/guides/integrate/service-accounts/authenticate-service-accounts.mdx b/apps/docs/content/guides/integrate/service-accounts/authenticate-service-accounts.mdx index 592c6e562..06e5cf5cb 100644 --- a/apps/docs/content/guides/integrate/service-accounts/authenticate-service-accounts.mdx +++ b/apps/docs/content/guides/integrate/service-accounts/authenticate-service-accounts.mdx @@ -5,53 +5,53 @@ sidebar_label: Authenticate service accounts import DocCardList from '@/components/docusaurus/doc-card-list'; -This guide explains ZITADEL service users and their role in facilitating secure machine-to-machine communication within your applications. +This guide explains ZITADEL service accounts and their role in facilitating secure machine-to-machine communication within your applications. -## What are Service Users? +## What are Service Accounts? -Service users in ZITADEL represent **non-human entities** within your system. +Service accounts 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 [Administrator](/concepts/structure/administrators) permissions are used to access ZITADEL's APIs, for example, to manage user resources. +Service accounts in combination with [Administrator](/concepts/structure/administrators) permissions are used to access ZITADEL's APIs, for example, to manage user resources. 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 +## Benefits of using Service Accounts ### Enhanced security -* **Principle of Least Privilege:** Grant service users only the minimum permissions they need, minimizing potential damage in case of compromise. -* **Distinct Credentials:** Avoid embedding sensitive credentials like API keys directly in code. Service user credentials can be rotated independently. +* **Principle of Least Privilege:** Grant service accounts only the minimum permissions they need, minimizing potential damage in case of compromise. +* **Distinct Credentials:** Avoid embedding sensitive credentials like API keys directly in code. Service account credentials can be rotated independently. ### Segregated authorization -Manage authorization for service users separately from human users, providing an extra layer of control. +Manage authorization for service accounts separately from human users, providing an extra layer of control. ### API and backend access -Service users offer a secure way to authenticate and access various API endpoints and protected backend services. +Service accounts offer a secure way to authenticate and access various API endpoints and protected backend services. -You can [use service users to access ZITADEL APIs](../zitadel-apis/access-zitadel-apis), follow the guides to learn how to access the different ZITADEL APIs. +You can [use service accounts to access ZITADEL APIs](../zitadel-apis/access-zitadel-apis), follow the guides to learn how to access the different ZITADEL APIs. While you can define the scopes and required information in your requests for your applications API endpoints, when using the ZITADEL APIs, you must include the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to gain access. ### Improved auditability -Actions performed by service users are clearly identifiable in logs, facilitating easier auditing and tracing. +Actions performed by service accounts are clearly identifiable in logs, facilitating easier auditing and tracing. Using the [Event API](../zitadel-apis/event-api) you can use these logs for further analysis or to integrate the logs with [external SOC / SIEM](../external-audit-log) systems. ## Authentication methods -ZITADEL supports two primary authentication methods for service users: +ZITADEL supports two primary authentication methods for service accounts: ### Private key JWT authentication #### How private key JWT authentication works -* Generate a private/public key pair associated with the service user. +* Generate a private/public key pair associated with the service account. * Sign JWTs with the private key. -* ZITADEL validates the signature using the service user's public key. +* ZITADEL validates the signature using the service account's public key. * JWTs can include expiration dates and scopes to control access. -Follow our guide on using [private key JWT client authentication](./private-key-jwt) to get started authenticating service users and applications. +Follow our guide on using [private key JWT client authentication](./private-key-jwt) to get started authenticating service accounts and applications. #### Benefits of private key JWT authentication @@ -71,22 +71,22 @@ Follow our guide on using [private key JWT client authentication](./private-key- ### Client credentials grant -* Presents a client ID and client secret associated with the service user. +* Presents a client ID and client secret associated with the service account. * Simpler than the JWT profile in specific scenarios. -Follow our guide on using [client credentials grant](./client-credentials) to get started authenticating service users and applications. +Follow our guide on using [client credentials grant](./client-credentials) to get started authenticating service accounts and applications. This method is still available in ZITADEL but is generally considered less secure than JWT due to: * **Centralized Validation:** Relies on the server to verify credentials for every request, potentially impacting performance and requiring more server resources. -* **Credentials Exposure:** Leaked client ID and secret could be used by attackers to impersonate the service user until rotation occurs. +* **Credentials Exposure:** Leaked client ID and secret could be used by attackers to impersonate the service account until rotation occurs. ### 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. +* **Ready-to-use tokens:** Generated for specific service accounts and can be directly included in the authorization header of API requests. * **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. +Follow our guide on using [personal access tokens](./personal-access-token) to get started authenticating service accounts and applications. PAT offer some benefits, such as: @@ -98,15 +98,15 @@ However, PATs also come with limitations: * **Revocation:** Requires deleting the PAT directly, potentially causing downtime if not managed carefully. * **Leakage:** PATs are long-lived tokens that can be readily used in API calls, if leaked the attacker can access all resources until the PAT is expired or deleted. Private key JWT and client credentials create a short-lived access token instead. -## Using Service Users +## Using Service Accounts -1. **Creation:** Access the ZITADEL management console and create a new service user. Assign a descriptive name that reflects its purpose. Follow our detailed guide on [how to create service users](../../manage/console/users). +1. **Creation:** Access the ZITADEL management console and create a new service account. Assign a descriptive name that reflects its purpose. Follow our detailed guide on [how to create service accounts](../../manage/console/users). 2. **Credentials:** Choose your preferred authentication method (JWT or Client Credentials) and securely store the generated credentials (private key, client secret). 3. **Making API Calls:** When your service needs to make an API call: * **For JWT:** Generate and sign a JWT. Include it in the "Authorization" header of your API request. * **For Client Credentials:** Include the client ID and client secret in your API request. * **For PATs:** Include the PAT directly in the "Authorization" header of your API request. -4. ZITADEL Verifies the credentials and authorizes the service user to perform the requested action based on its granted permissions. +4. ZITADEL Verifies the credentials and authorizes the service account to perform the requested action based on its granted permissions. We have guides for the different authentication methods: @@ -116,19 +116,19 @@ We have guides for the different authentication methods: ## Important considerations -* **Secure Credentials:** Treat service user credentials (private keys, client secrets) with utmost care. Store them securely, similar to any other sensitive information like API keys or passwords. +* **Secure Credentials:** Treat service account credentials (private keys, client secrets) with utmost care. Store them securely, similar to any other sensitive information like API keys or passwords. * **Expiry Management:** Set appropriate expiration dates for JWTs and regularly rotate all credentials to maintain strong security practices. -* **Permission Granting:** Adhere to the principle of least privilege by granting only the specific permissions required for a service user's function. +* **Permission Granting:** Adhere to the principle of least privilege by granting only the specific permissions required for a service account's function. ## Choosing the right authentication method -For most service user scenarios in ZITADEL, [private key JWT authentication](./private-key-jwt) is the recommended choice due to its benefits in security, performance, and control. +For most service account scenarios in ZITADEL, [private key JWT authentication](./private-key-jwt) is the recommended choice due to its benefits in security, performance, and control. However, [client credentials authentication](./client-credentials) might be considered in specific situations where simplicity and trust between servers are priorities. ## Further resources -* Read about the [different methods to authenticate service users](./authenticate-service-accounts) -* [Service User API reference](/reference/api/user) +* Read about the [different methods to authenticate service accounts](./authenticate-service-accounts) +* [Service Account 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) * Validate access tokens with [token introspection with private key jwt](../token-introspection/private-key-jwt.mdx) diff --git a/apps/docs/content/guides/integrate/service-accounts/client-credentials.mdx b/apps/docs/content/guides/integrate/service-accounts/client-credentials.mdx index fc01b3231..741863ad5 100644 --- a/apps/docs/content/guides/integrate/service-accounts/client-credentials.mdx +++ b/apps/docs/content/guides/integrate/service-accounts/client-credentials.mdx @@ -1,17 +1,17 @@ --- -title: Configure client credential authentication for service users +title: Configure client credential authentication for service accounts 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-accounts) and client applications within ZITADEL. +This guide demonstrates how developers can leverage Client Credential authentication to secure communication between [service accounts](/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-accounts) as alternative to the [JWT profile authentication](./authenticate-service-accounts). -## Steps to authenticate a Service User with client credentials +## Steps to authenticate a Service Account with client credentials -### 1. Create a Service User with a client secret +### 1. Create a Service Account with a client secret -1. Navigate to Service Users +1. Navigate to Service Accounts 2. Click on **New** 3. Enter a username and a display name 4. Click on **Create** @@ -23,11 +23,11 @@ Make sure to copy in particular the ClientSecret. You won't be able to retrieve If you lose it, you will have to generate a new one. -![](../../../../public/img/console_serviceusers_secret.gif) +![](../../../../public/img/console_serviceaccounts_secret.gif) -### 2. Authenticating a service user and request a token +### 2. Authenticating a service account and request a token -In this step, we will authenticate a service user and receive an access_token to use against the ZITADEL API. +In this step, we will authenticate a service account and receive an access_token to use against the ZITADEL API. You will need to craft a POST request to ZITADEL's token endpoint: @@ -48,7 +48,7 @@ curl --request POST \ If you want to access ZITADEL APIs, make sure to include the required scopes `urn:zitadel:iam:org:project:id:zitadel:aud`. Read our guide [how to access ZITADEL APIs](../zitadel-apis/access-zitadel-apis) to learn more. -**Important Note:** If the service user token needs to be validated using token introspection, ensure you include the `urn:zitadel:iam:org:project:id:{projectid}:aud` scope in your token request. +**Important Note:** If the service account token needs to be validated using token introspection, ensure you include the `urn:zitadel:iam:org:project:id:{projectid}:aud` scope in your token request. Without this, token introspection will fail. You should receive a successful response with `access_token`, `token_type` and time to expiry in seconds as `expires_in`. @@ -64,15 +64,15 @@ Content-Type: application/json } ``` -Per default a service user will get an opaque access token. -If you want to get a Jason Web Token (JWT) as an access token for your user, you can change the token type in the general settings of your service account. +Per default a service account will get an opaque access token. +If you want to get a JSON Web Token (JWT) as an access token for your user, you can change the token type in the general settings of your service account. To learn more about opaque and JWT tokens read our [Opaque Tokens in ZITADEL: Enhancing Application Security](/concepts/knowledge/opaque-tokens) Guide -![](../../../../public/img/console_service_user_tokentype.png) +![](../../../../public/img/console_service_account_tokentype.png) ### 3. Include the access token in the authorization header -When making API requests on behalf of the service user, include the generated token in the "Authorization" header with the "Bearer" prefix. +When making API requests on behalf of the service account, include the generated token in the "Authorization" header with the "Bearer" prefix. ```bash curl --request POST \ @@ -84,7 +84,7 @@ curl --request POST \ ## Accessing ZITADEL APIs You might want to access ZITADEL APIs to manage resources, such as users, or to validate tokens sent to your backend service. -Follow our guides on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) to use the ZITADEL APIs with your service user using client credentials. +Follow our guides on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) to use the ZITADEL APIs with your service account using client credentials. ### Token introspection @@ -97,12 +97,12 @@ Follow our [guide on token introspection with client credentials](../token-intro * **Store private keys securely:** **Never share or embed the private key in your code or application.** Consider using secure key management solutions. * **Set appropriate expiration times:** Limit the validity period of tokens to minimize the impact of potential compromise. -By following these steps and adhering to security best practices, you can effectively secure service user and client application communication within ZITADEL using client credential authentication. +By following these steps and adhering to security best practices, you can effectively secure service account and client application communication within ZITADEL using client credential authentication. ## Notes -* Read about the [different methods to authenticate service users](./authenticate-service-accounts) -* [Service User API reference](/reference/api/user) +* Read about the [different methods to authenticate service accounts](./authenticate-service-accounts) +* [Service Account 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) * Validate access tokens with [token introspection with basic auth](../token-introspection/basic-auth) diff --git a/apps/docs/content/guides/integrate/service-accounts/personal-access-token.mdx b/apps/docs/content/guides/integrate/service-accounts/personal-access-token.mdx index 4e37351c4..f9e28547d 100644 --- a/apps/docs/content/guides/integrate/service-accounts/personal-access-token.mdx +++ b/apps/docs/content/guides/integrate/service-accounts/personal-access-token.mdx @@ -1,16 +1,16 @@ --- -title: Configure personal access token authentication for service users +title: Configure personal access token authentication for service accounts sidebar_label: Personal access token authentication --- A Personal Access Token (PAT) is a ready-to-use token that can be used as an _Authorization_ header. -At the moment ZITADEL only allows PATs for machine accounts (service users). +At the moment ZITADEL only allows PATs for service accounts. -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). +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 accounts](./authenticate-service-accounts). -## Create a Service User with a PAT +## Create a Service Account with a PAT -1. Navigate to Service Users +1. Navigate to Service Accounts 2. Click on **New** 3. Enter a username and a display name 4. Click on the Personal Access Token menu point in the detail of your user @@ -22,11 +22,11 @@ It is an alternative to the [private key JWT](./private-key-jwt) and [client cre ## Grant role for ZITADEL -To be able to access the ZITADEL APIs, your service user needs permissions to ZITADEL. +To be able to access the ZITADEL APIs, your service account needs permissions to ZITADEL. 1. Go to the detail page of your organization 2. Click in the top right corner the "+" button -3. Search for your service user +3. Search for your service account 4. Give the user the role you need — for example, we choose Org Owner (More about [ZITADEL Permissions](/guides/manage/console/administrators)) ![](../../../../public/img/guides/console-service-user-org-owner.gif) @@ -34,7 +34,7 @@ To be able to access the ZITADEL APIs, your service user needs permissions to ZI ## Accessing ZITADEL APIs You might want to access ZITADEL APIs to manage resources, such as users, or to validate tokens sent to your backend service. -Follow our guides on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) to use the ZITADEL APIs with your service user. +Follow our guides on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) to use the ZITADEL APIs with your service account. ### Token introspection @@ -45,7 +45,7 @@ Follow our [guide on token introspection with private key JWT](../token-introspe ## Call ZITADEL API with PAT Because the PAT is a ready-to-use token, you can add it as an Authorization Header and send it in your requests to the ZITADEL API. -In this example we read the organization of the service user. +In this example we read the organization of the service account. ```bash curl --request GET \ @@ -55,7 +55,7 @@ curl --request GET \ ## Client application authentication -The above steps demonstrate service user authentication. +The above steps demonstrate service account authentication. If your application also needs to authenticate itself, you can utilize [Client Credentials Grant](./client-credentials). Refer to ZITADEL documentation for details on this alternative method. @@ -65,4 +65,4 @@ Refer to ZITADEL documentation for details on this alternative method. * **Set appropriate JWT expiration times:** Limit the validity period of tokens to minimize the impact of potential compromise. * **Implement proper error handling:** Handle situations where JWT verification fails or tokens are expired. -By following these steps and adhering to security best practices, you can effectively secure service user and client application communication within ZITADEL using private key JWT authentication. +By following these steps and adhering to security best practices, you can effectively secure service account and client application communication within ZITADEL using private key JWT authentication. diff --git a/apps/docs/content/guides/integrate/service-accounts/private-key-jwt.mdx b/apps/docs/content/guides/integrate/service-accounts/private-key-jwt.mdx index 2118eb8a3..260682976 100644 --- a/apps/docs/content/guides/integrate/service-accounts/private-key-jwt.mdx +++ b/apps/docs/content/guides/integrate/service-accounts/private-key-jwt.mdx @@ -1,23 +1,23 @@ --- -title: Configure private key JWT authentication for service users +title: Configure private key JWT authentication for service accounts sidebar_label: Private key JWT authentication --- -This guide explains how developers can use private key JWT authentication to secure communication between service users and client applications in ZITADEL. +This guide explains how developers can use private key JWT authentication to secure communication between service accounts and client applications in ZITADEL. 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-accounts), including their benefits, drawbacks, and security considerations. +Read more about the [different authentication methods for service accounts](./authenticate-service-accounts), including their benefits, drawbacks, and security considerations. #### How private key JWT authentication works -1. Generate a private/public key pair associated with the service user. +1. Generate a private/public key pair associated with the service account. 2. The authorization server stores the public key. 3. The authorization server returns the private key as a JSON file. 4. The developer configures the client application to use the private key. -5. The client creates a JWT assertion with the subject set to the service user and signs the JWT with the private key. +5. The client creates a JWT assertion with the subject set to the service account and signs the JWT with the private key. 6. The client application requests a token from ZITADEL by sending the `client_assertion`. -7. The authorization server validates the signature using the service user's public key. +7. The authorization server validates the signature using the service account's public key. 8. The authorization server returns an OAuth `access_token`. 9. The client sends an API request, including the `access_token` in the Authorization header. 10. The resource server validates the JWT with [token introspection](../token-introspection/). @@ -28,32 +28,32 @@ Read more about the [different authentication methods for service users](./authe A code library or framework that supports JWT generation and verification (such as `pyjwt` for Python or `jsonwebtoken` for Node.js). -## Steps to authenticate a Service User with private JWT +## Steps to authenticate a Service Account with private JWT -Follow these steps to authenticate a service user and obtain an access token for subsequent requests. +Follow these steps to authenticate a service account and obtain an access token for subsequent requests. -### 1. Create a Service User +### 1. Create a Service Account -1. Navigate to **Service Users**. +1. Navigate to **Service Accounts**. 2. Click on **New**. 3. Enter a username and a display name. 4. Click on **Create**. -### 2. Register a private key for your service user +### 2. Register a private key for your service account You can let ZITADEL generate a private key for you, **or** upload your own (externally generated) public key. Choose one of the following: #### Option A: Generate and download a private key from ZITADEL -1. Open the ZITADEL web console and go to your service user. +1. Open the ZITADEL web console and go to your service account. 2. Click on the **Keys** tab. 3. Click **New**. 4. Optionally set an expiration date for the key, or leave empty for no expiration. 5. Click **Download** and save the JSON key file securely. -#### Option B: Register an existing public key for your service user +#### Option B: Register an existing public key for your service account -If you already have a key pair, you can upload the public key for your service user. For example, to generate a key pair using OpenSSL: +If you already have a key pair, you can upload the public key for your service account. For example, to generate a key pair using OpenSSL: ```bash # generate key pair @@ -73,7 +73,7 @@ If you generate a key in ZITADEL, make sure to download and securely store the k If you set an expiration date when generating a key in ZITADEL, that key will expire at midnight on the specified day. -![](../../../../public/img/console_serviceusers_new_key.gif) +![](../../../../public/img/console_serviceaccounts_new_key.gif) If you let ZITADEL generate a key for you and download the JSON file, it will look similar to the example below. In this ZITADEL-generated key file, the `key` property contains the _private_ key for your service account. Store this JSON securely and never share your private key. ZITADEL automatically stores the public key component, so you do not need to upload it. @@ -130,7 +130,7 @@ There are also [many libraries](https://jwt.io/#libraries-io) available for gene import jwt import datetime -# Replace with your service user ID and private key +# Replace with your service account ID and private key service_user_id = "your_service_user_id" private_key = "-----BEGIN PRIVATE KEY-----\nYOUR_PRIVATE_KEY\n-----END PRIVATE KEY-----" key_id = "your_key_id" @@ -178,7 +178,7 @@ curl --request POST \ If you want to access ZITADEL APIs, make sure to include the required scope `urn:zitadel:iam:org:project:id:zitadel:aud`. See our guide on [how to access ZITADEL APIs](../zitadel-apis/access-zitadel-apis) for more details. -**Important Note:** If the service user token must be validated using token introspection, you must include the `urn:zitadel:iam:org:project:id:{projectid}:aud` scope in your token request. +**Important Note:** If the service account token must be validated using token introspection, you must include the `urn:zitadel:iam:org:project:id:{projectid}:aud` scope in your token request. If you do not include this, token introspection will fail. A successful response will include the `access_token`, `token_type`, and the time to expiry in seconds (`expires_in`): @@ -196,7 +196,7 @@ Content-Type: application/json ### 5. Include the access token in the Authorization header -When making API requests as the service user, include the generated token in the "Authorization" header with the "Bearer" prefix. +When making API requests as the service account, include the generated token in the "Authorization" header with the "Bearer" prefix. ```bash curl --request POST \ @@ -208,7 +208,7 @@ curl --request POST \ ## Accessing ZITADEL APIs You may use ZITADEL APIs to manage resources (e.g., users) or to validate tokens received by your backend service. -Follow our guide on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) with your service user. +Follow our guide on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) with your service account. ### Token introspection @@ -218,7 +218,7 @@ See our [guide on token introspection with private key JWT](../token-introspecti ## Client application authentication -The steps above describe service user authentication. +The steps above describe service account authentication. If your application itself also needs authentication, you can use the [Client Credentials Grant](./client-credentials). See the ZITADEL documentation for additional details on this approach. @@ -228,7 +228,7 @@ See the ZITADEL documentation for additional details on this approach. * **Set appropriate JWT expiration times:** Limit token validity to reduce risk in the event of a compromise. * **Implement proper error handling:** Handle cases where JWT verification fails or tokens are expired. -By following these steps and adhering to best practices, you can securely manage service user and client application authentication within ZITADEL using private key JWTs. +By following these steps and adhering to best practices, you can securely manage service account and client application authentication within ZITADEL using private key JWTs. ## Notes diff --git a/apps/docs/content/guides/integrate/token-introspection/index.mdx b/apps/docs/content/guides/integrate/token-introspection/index.mdx index 0cae1dc11..73157eee3 100644 --- a/apps/docs/content/guides/integrate/token-introspection/index.mdx +++ b/apps/docs/content/guides/integrate/token-introspection/index.mdx @@ -23,16 +23,16 @@ If you have an API that behaves as an OAuth resource server that can be accessed - [JSON Web Token (JWT) Profile (Recommended)](/guides/integrate/token-introspection/private-key-jwt) - [Basic Authentication](/guides/integrate/token-introspection/basic-auth) -## Service users +## Service accounts -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-accounts/authenticate-service-accounts). +If there are client APIs or systems that need to access other protected APIs, these APIs or systems must be declared as [service accounts](/guides/manage/console/users-overview). +A service account is not considered an application type in ZITADEL. +Read the introduction on how to [authenticate service accounts](/guides/integrate/service-accounts/authenticate-service-accounts). ## Further references - [Introspection API reference](/apis/openidoauth/endpoints#token-endpoint) - [JWT vs. opaque tokens](/concepts/knowledge/opaque-tokens) -- [Python examples for securing an API and invoking it as a service user](https://github.com/zitadel/examples-api-access-and-token-introspection) +- [Python examples for securing an API and invoking it as a service account](https://github.com/zitadel/examples-api-access-and-token-introspection) diff --git a/apps/docs/content/guides/integrate/token-introspection/private-key-jwt.mdx b/apps/docs/content/guides/integrate/token-introspection/private-key-jwt.mdx index b88f4a0c4..9d623c951 100644 --- a/apps/docs/content/guides/integrate/token-introspection/private-key-jwt.mdx +++ b/apps/docs/content/guides/integrate/token-introspection/private-key-jwt.mdx @@ -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-accounts/private-key-jwt). +If you're looking to set up Private Key JWT authentication specifically for Service Accounts, see our dedicated guide [here](/guides/integrate/service-accounts/private-key-jwt). ## Register an Application & Generate a Key Pair diff --git a/apps/docs/content/guides/integrate/zitadel-apis/_accessing_zitadel_api.mdx b/apps/docs/content/guides/integrate/zitadel-apis/_accessing_zitadel_api.mdx index 35b849bdb..7523a29df 100644 --- a/apps/docs/content/guides/integrate/zitadel-apis/_accessing_zitadel_api.mdx +++ b/apps/docs/content/guides/integrate/zitadel-apis/_accessing_zitadel_api.mdx @@ -1,6 +1,6 @@ ## Accessing ZITADEL APIs -In this step, we will authenticate a service user and receive an access_token to use against the ZITADEL API. +In this step, we will authenticate a service account and receive an access_token to use against the ZITADEL API. You will need to craft a POST request to ZITADEL's token endpoint: @@ -32,7 +32,7 @@ Content-Type: application/json } ``` -In this step we will authenticate a service user and receive an access_token to use against the ZITADEL API. +In this step we will authenticate a service account and receive an access_token to use against the ZITADEL API. You will need to craft a POST request to ZITADEL's token endpoint: diff --git a/apps/docs/content/guides/integrate/zitadel-apis/access-zitadel-apis.mdx b/apps/docs/content/guides/integrate/zitadel-apis/access-zitadel-apis.mdx index a036fd8c5..a6d0a55ee 100644 --- a/apps/docs/content/guides/integrate/zitadel-apis/access-zitadel-apis.mdx +++ b/apps/docs/content/guides/integrate/zitadel-apis/access-zitadel-apis.mdx @@ -2,7 +2,7 @@ title: Access ZITADEL APIs --- -This guide explains what ZITADEL APIs are and how to access ZITADEL APIs using a service user to manage all types of resources and settings. +This guide explains what ZITADEL APIs are and how to access ZITADEL APIs using a service account to manage all types of resources and settings. ## What are the ZITADEL APIs @@ -27,15 +27,15 @@ 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-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. +1. **Create a service account**: A service account 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 accounts 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 account, giving it permission to make changes to certain resources in ZITADEL. 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 The Auth API can be used for all operations on the requesting user, meaning the user id in the `sub` claim of the used token. -Using this API doesn't require a service user to be authenticated. +Using this API doesn't require a service account to be authenticated. Instead, you call the Auth API with the token of the user. [Reference documentation for authentication API](/apis/introduction#authentication) @@ -43,24 +43,24 @@ Instead, you call the Auth API with the token of the user. ### Accessing System API With the System API developers can manage different ZITADEL instances. -The System API can't be accessed by service users and requires a special configuration and authentication that can be found in our [guide to access ZITADEL's System API](./access-zitadel-system-api). +The System API can't be accessed by service accounts and requires a special configuration and authentication that can be found in our [guide to access ZITADEL's System API](./access-zitadel-system-api). [Reference documentation for system API](/apis/introduction#system) -## 1. Create a service user +## 1. Create a service account -First, you need to create a new service user through the management console or ZITADEL APIs. +First, you need to create a new service account through the management console or ZITADEL APIs. Via Management Console: -1. In an organization, navigate to Users > Service Users +1. In an organization, navigate to Users > Service Accounts 2. Click on **New** 3. Enter a username and a display name 4. Click on **Create** Via APIs23: * [Create User (Machine)](/reference/api/management/zitadel.management.v1.ManagementService.AddMachineUser) -## 2. Grant an Administrator Role to the Service User +## 2. Grant an Administrator Role to the Service Account ZITADEL Administrators are users who have permission to manage ZITADEL itself. There are different levels of administrators. @@ -72,21 +72,21 @@ There are different levels of administrators. There are different roles on each level. You can find more about the different roles here: [ZITADEL Administrator Roles](/guides/manage/console/administrators#roles) -To be able to access the ZITADEL APIs, your service user needs permissions to ZITADEL. +To be able to access the ZITADEL APIs, your service account needs permissions to ZITADEL. 1. Go to the detail page of your organization 2. Click in the top right corner the "+" button -3. Search for your service user +3. Search for your service account 4. Give the user the role you need — for example, we choose Org Owner (More about [ZITADEL Permissions](/guides/manage/console/administrators)) ![](../../../../public/img/console_org_owner_add.gif) -## 3. Authenticate service user and request token +## 3. Authenticate service account and request token -Service users can be authenticated using private key JWT, client credentials, or personal access tokens. -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. +Service accounts can be authenticated using private key JWT, client credentials, or personal access tokens. +The [service account 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). +This guide covers a specific case of service account 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. This scope will add the ZITADEL APIs to the audience of the access token. ZITADEL APIs will check if they are in the audience of the access token and reject the token in case they are not in the audience. @@ -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 a 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). +Follow the steps in this guide to [generate a key file](../service-accounts/private-key-jwt#2-register-a-private-key-for-your-service-account) 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. @@ -134,7 +134,7 @@ Content-Type: application/json ``` Use the access_token in the Authorization header to make requests to the ZITADEL APIs. -In the following example, we read the organization of the service user. +In the following example, we read the organization of the service account. ```bash curl --request GET \ @@ -146,11 +146,11 @@ curl --request GET \ Get the client id and client secret by -1. navigating to the service user, then +1. navigating to the service account, then 2. Open **Actions** in the top right corner and click on **Generate Client Secret** 3. Copy the **ClientID** and **ClientSecret** from the dialog -![](../../../../public/img/console_serviceusers_secret.gif) +![](../../../../public/img/console_serviceaccounts_secret.gif) With the ClientId and ClientSecret from the prior step, you will need to craft a POST request to ZITADEL's token endpoint. @@ -160,7 +160,7 @@ With the ClientId and ClientSecret from the prior step, you will need to craft a This is possible by sending a [reserved scope](/apis/openidoauth/scopes) for the audience. Use the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to include the ZITADEL project id in your audience -In this step we will authenticate a service user and receive an access_token to use against the ZITADEL API. +In this step we will authenticate a service account and receive an access_token to use against the ZITADEL API. #### Basic authentication @@ -206,7 +206,7 @@ Content-Type: application/json ``` Because the received token includes the `urn:zitadel:iam:org:project:id:zitadel:aud` scope, we can send it in your requests to the ZITADEL API as the Authorization Header. -In this example we read the organization of the service user. +In this example, we read the organization of the service account. ```bash curl --request GET \ @@ -219,7 +219,7 @@ curl --request GET \ A Personal Access Token (PAT) is a ready-to-use token that can be used as an _Authorization_ header. Because the PAT is a ready-to-use token, you can add it as an Authorization Header and send it in your requests to the ZITADEL API. -In this example, we read the organization of the service user. +In this example, we read the organization of the service account. ```bash curl --request GET \ @@ -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-accounts/authenticate-service-accounts) +- Read about the [different methods to authenticate service accounts](../service-accounts/authenticate-service-accounts) diff --git a/apps/docs/content/guides/integrate/zitadel-apis/example-zitadel-api-with-dot-net.mdx b/apps/docs/content/guides/integrate/zitadel-apis/example-zitadel-api-with-dot-net.mdx index b7a19dbf6..64be257da 100644 --- a/apps/docs/content/guides/integrate/zitadel-apis/example-zitadel-api-with-dot-net.mdx +++ b/apps/docs/content/guides/integrate/zitadel-apis/example-zitadel-api-with-dot-net.mdx @@ -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-accounts/authenticate-service-accounts) + - [Service Accounts](/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. @@ -107,7 +107,7 @@ To use the auth API you will not need a specific role, because only an authentic For accessing the admin or management API the user will need some specific roles. If you encountered an error (e.g. `code = PermissionDenied desc = No matching permissions found`), -ensure your service user has the required permissions by assigning the `ORG_OWNER` or `ORG_OWNER_VIEWER` role +ensure your service account has the required permissions by assigning the `ORG_OWNER` or `ORG_OWNER_VIEWER` role and check the mentioned [guides](#prerequisites) at the beginning. If you've run into any other problem, don't hesitate to contact us or raise an issue on [ZITADEL](https://github.com/zitadel/zitadel/issues) or in the [SDK](https://github.com/zitadel/zitadel-go/issues). diff --git a/apps/docs/content/guides/integrate/zitadel-apis/example-zitadel-api-with-go.mdx b/apps/docs/content/guides/integrate/zitadel-apis/example-zitadel-api-with-go.mdx index 30bf04ee4..784f6dce5 100644 --- a/apps/docs/content/guides/integrate/zitadel-apis/example-zitadel-api-with-go.mdx +++ b/apps/docs/content/guides/integrate/zitadel-apis/example-zitadel-api-with-go.mdx @@ -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-accounts/authenticate-service-accounts) + - [Service Accounts](/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. @@ -69,7 +69,7 @@ This will output something similar to: You have successfully used the ZITADEL Go SDK to call the management API! If you encountered an error (e.g. `code = PermissionDenied desc = No matching permissions found`), -ensure your service user has the required permissions by assigning the `ORG_OWNER` or `ORG_OWNER_VIEWER` role +ensure your service account has the required permissions by assigning the `ORG_OWNER` or `ORG_OWNER_VIEWER` role and check the mentioned [guides](#prerequisites) at the beginning. If you've run into any other problem, don't hesitate to contact us or raise an issue on [ZITADEL](https://github.com/zitadel/zitadel/issues) or in the [SDK](https://github.com/zitadel/zitadel-go/issues). diff --git a/apps/docs/content/guides/manage/console/_add_administrator.mdx b/apps/docs/content/guides/manage/console/_add_administrator.mdx index ad6aa97d7..fa8cb45da 100644 --- a/apps/docs/content/guides/manage/console/_add_administrator.mdx +++ b/apps/docs/content/guides/manage/console/_add_administrator.mdx @@ -1,5 +1,5 @@ When adding a new administrator, you can select multiple roles, some of which are only allowed to read data. -This can be especially useful if you add service users for one of your projects where you only need read access. +This can be especially useful if you add service account for one of your projects where you only need read access. By default, you will only search for users within the selected organization. If you like to give a role to a user outside the organization, you need to switch to the global search and type the exact loginname of the users. This will prevent users from guessing users from other organizations. diff --git a/apps/docs/content/guides/manage/console/_create-user.mdx b/apps/docs/content/guides/manage/console/_create-user.mdx index 0d0c286a5..815f5e2ba 100644 --- a/apps/docs/content/guides/manage/console/_create-user.mdx +++ b/apps/docs/content/guides/manage/console/_create-user.mdx @@ -29,11 +29,11 @@ In this case please enable the Feature Flag "Use V2 Api in Management Console fo If no password is set initially, the initialization mail prompting the user to set his password is sent. - + Add Service User diff --git a/apps/docs/content/guides/manage/console/users-overview.mdx b/apps/docs/content/guides/manage/console/users-overview.mdx index 780ebde86..db621d752 100644 --- a/apps/docs/content/guides/manage/console/users-overview.mdx +++ b/apps/docs/content/guides/manage/console/users-overview.mdx @@ -28,7 +28,7 @@ Service accounts represent machines, backend services, or IoT devices requiring * **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. -To see how service users are utilized in practice, check out our [NextJS B2B Demo application](https://github.com/zitadel/zitadel-nextjs-b2b). +To see how service accounts are utilized in practice, check out our [NextJS B2B Demo application](https://github.com/zitadel/zitadel-nextjs-b2b). ### Federated Users Federated users are identities managed by a third-party Identity Provider (IdP) such as Google, Azure AD, or GitHub. diff --git a/apps/docs/content/guides/manage/console/users.mdx b/apps/docs/content/guides/manage/console/users.mdx index 151b705e3..47edb826b 100644 --- a/apps/docs/content/guides/manage/console/users.mdx +++ b/apps/docs/content/guides/manage/console/users.mdx @@ -8,7 +8,7 @@ import CreateUser from './_create-user.mdx'; ZITADEL differs two different types of users: - Users (Humans) -- Service Users (Machine Accounts) +- Service Accounts User types @@ -18,7 +18,7 @@ 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. +Service accounts 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 diff --git a/apps/docs/content/guides/manage/terraform-provider.mdx b/apps/docs/content/guides/manage/terraform-provider.mdx index ace677f1c..753167722 100644 --- a/apps/docs/content/guides/manage/terraform-provider.mdx +++ b/apps/docs/content/guides/manage/terraform-provider.mdx @@ -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-accounts/authenticate-service-accounts) with [enough authorization](/guides/manage/console/administrators) to manage the desired resources +- [A service account](/guides/integrate/service-accounts/authenticate-service-accounts) with [enough authorization](/guides/manage/console/administrators) to manage the desired resources ## Manage ZITADEL resources through terraform diff --git a/apps/docs/content/guides/manage/user/scim2.mdx b/apps/docs/content/guides/manage/user/scim2.mdx index 380630ae9..a7fac8632 100644 --- a/apps/docs/content/guides/manage/user/scim2.mdx +++ b/apps/docs/content/guides/manage/user/scim2.mdx @@ -19,14 +19,14 @@ Zitadel uses provisioning domains to scope the handling of the SCIM **`externalI ### Setting a provisioning domain -A provisioning domain can be assigned to a **machine user** by adding the following metadata entry: +A provisioning domain can be assigned to a **service account** by adding the following metadata entry: - **Key:** `urn:zitadel:scim:provisioningDomain` - **Value:** the name of the provisioning domain ### How Zitadel stores `externalId` -If a machine user has a provisioning domain set, any SCIM `externalId` provided during user provisioning or lookup is stored under: +If a service account has a provisioning domain set, any SCIM `externalId` provided during user provisioning or lookup is stored under: `urn:zitadel:scim:{provisioningDomain}:externalId` If *no* provisioning domain is configured, Zitadel falls back to a simplified metadata key: diff --git a/apps/docs/content/guides/migrate/sources/auth0.mdx b/apps/docs/content/guides/migrate/sources/auth0.mdx index f6c268a63..ce5bdd637 100644 --- a/apps/docs/content/guides/migrate/sources/auth0.mdx +++ b/apps/docs/content/guides/migrate/sources/auth0.mdx @@ -117,7 +117,7 @@ The tool will merge both objects into a single one in the importBody.json output ### 5.1. Obtain Access Token (or PAT) for API Access -To call the ZITADEL Admin API, you need to authenticate using a **Service User** with the `IAM_OWNER` Manager permissions. +To call the ZITADEL Admin API, you need to authenticate using a **Service Account** with the `IAM_OWNER` Manager permissions. There are two recommended authentication methods: @@ -127,7 +127,7 @@ There are two recommended authentication methods: - **Personal Access Token (PAT)** [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-accounts/authenticate-service-accounts#authentication-methods) +**Reference:** [Service Accounts & API Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts#authentication-methods) ### 5.2. Import Data with the ZITADEL API diff --git a/apps/docs/content/guides/migrate/sources/keycloak.mdx b/apps/docs/content/guides/migrate/sources/keycloak.mdx index ee6e2e26a..05747a83d 100644 --- a/apps/docs/content/guides/migrate/sources/keycloak.mdx +++ b/apps/docs/content/guides/migrate/sources/keycloak.mdx @@ -100,7 +100,7 @@ The tool will generate `importBody.json`, which is ready for importing into ZITA ### 5.1. Obtain Access Token (or PAT) for API Access -To call the ZITADEL Management API, you need to authenticate using a **Service User** with the `IAM_OWNER` Manager permissions. +To call the ZITADEL Management API, you need to authenticate using a **Service Account** with the `IAM_OWNER` Manager permissions. There are two recommended authentication methods: @@ -110,7 +110,7 @@ There are two recommended authentication methods: * **Personal Access Token (PAT)** [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-accounts/authenticate-service-accounts#authentication-methods) +**Reference:** [Service Accounts & API Authentication](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts#authentication-methods) --- diff --git a/apps/docs/content/guides/migrate/sources/zitadel.mdx b/apps/docs/content/guides/migrate/sources/zitadel.mdx index b1370025d..45a3961ef 100644 --- a/apps/docs/content/guides/migrate/sources/zitadel.mdx +++ b/apps/docs/content/guides/migrate/sources/zitadel.mdx @@ -30,12 +30,12 @@ Note that the resources will be migrated without the event stream. This means th ## Authorization -You need a PAT from a service user with instance Owner permissions in both the source and target system. +You need a PAT from a service account with instance Owner permissions in both the source and target system. ### Source system 1. Go to your default organization -2. Create a service user "import_user" with Access Token Type "Bearer" +2. Create a service account "import_user" with Access Token Type "Bearer" 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/administrators) with the role "instance Owner" @@ -45,7 +45,7 @@ Save the PAT to the environment variable `PAT_EXPORT_TOKEN` and the source domai ### Target system 1. Go to your default organization -2. Create a service user "export_user" with Access Token Type "Bearer" +2. Create a service account "export_user" with Access Token Type "Bearer" 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/administrators) with the role "instance Owner" diff --git a/apps/docs/content/guides/solution-scenarios/b2b.mdx b/apps/docs/content/guides/solution-scenarios/b2b.mdx index e659e3e33..3e25d8c1a 100644 --- a/apps/docs/content/guides/solution-scenarios/b2b.mdx +++ b/apps/docs/content/guides/solution-scenarios/b2b.mdx @@ -16,7 +16,7 @@ B2B can be a simple scenario where an organization only shares one of its projec ## Sample scenario Octagon is a fictitious company which is used throughout this guide to explain the details and key concepts of such a B2B scenario. -Octagon tries to solve multiple tasks in the banking field. Its portfolio includes several applications for their employees, customers, and partners. Some of which are web-based, some of which are used by machine users only. +Octagon tries to solve multiple tasks in the banking field. Its portfolio includes several applications for their employees, customers, and partners. Some of which are web-based, some of which are used by service accounts only. ### Portal Application @@ -71,7 +71,7 @@ In this scenario, Dimitri and Michael share the same organization Pentagon, wher > Note: Roles are meant for internal business logic and therefore need to be validated separately, none of the users described are allowed to create user grants, at least if they do not own a ZITADEL administrator role. -If you made a dashboard where some users are able to create user grants, the Management API to do such operations should be triggered with the personal access token of the users, not with a token of a machine user, to create a meaningful audit log. +If you made a dashboard where some users are able to create user grants, the Management API to do such operations should be triggered with the personal access token of the users, not with a token of a service account, to create a meaningful audit log. If you had such a use case, ZITADEL administrator roles must be assigned to those users. ### Noteworthy diff --git a/apps/docs/content/guides/solution-scenarios/restrict-console.mdx b/apps/docs/content/guides/solution-scenarios/restrict-console.mdx index 641513de4..1032076a8 100644 --- a/apps/docs/content/guides/solution-scenarios/restrict-console.mdx +++ b/apps/docs/content/guides/solution-scenarios/restrict-console.mdx @@ -72,7 +72,7 @@ curl -L -X PUT "https://${CUSTOM_DOMAIN}/management/v1/projects/${PROJECT_ID}" \ Where - `${CUSTOM_DOMAIN}` is your Custom Domain, f.e. mydemo.zitadel.cloud -- `${PAT}` is your service user's personal access token +- `${PAT}` is your service account's personal access token - `${PROJECT_ID}` is the default-project's ID that can be found in Management Console see screenshot above You should now be able to log in with users of the organization that have the grant (in this example users of the organization "Customer-A"). diff --git a/apps/docs/content/guides/start/quickstart.mdx b/apps/docs/content/guides/start/quickstart.mdx index 47b031264..e887a3497 100644 --- a/apps/docs/content/guides/start/quickstart.mdx +++ b/apps/docs/content/guides/start/quickstart.mdx @@ -1036,7 +1036,7 @@ You’ve successfully integrated ZITADEL into an application. 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-accounts/personal-access-token) with the [`IAM_OWNER`](/guides/manage/console/administrators) role to revert any login UI misconfigurations using the API. + 1. **Generate a backup PAT:** Create a [Service Account Personal Access Token](/guides/integrate/service-accounts/personal-access-token) with the [`IAM_OWNER`](/guides/manage/console/administrators) role to revert any login UI misconfigurations using the API. 2. **Add a second Instance Administrator:** Always designate at least one [**second instance administrator**](/guides/manage/console/administrators). diff --git a/apps/docs/content/legal/policies/account-lockout-policy.mdx b/apps/docs/content/legal/policies/account-lockout-policy.mdx index 10b9d6924..3479fcd27 100644 --- a/apps/docs/content/legal/policies/account-lockout-policy.mdx +++ b/apps/docs/content/legal/policies/account-lockout-policy.mdx @@ -54,7 +54,7 @@ Our support team will follow up with additional verification steps if needed. ### Instance Manager access recovery -If you need to recover a Manager account to an instance, please make sure you can't recover the account via another user or service user with Manager permissions. +If you need to recover a Manager account to an instance, please make sure you can't recover the account via another user or service account with Manager permissions. Please visit the [support page in the customer portal](https://zitadel.com/admin/support): diff --git a/apps/docs/content/product/_sdk_v3.mdx b/apps/docs/content/product/_sdk_v3.mdx index 083dccc81..9dd5c03fb 100644 --- a/apps/docs/content/product/_sdk_v3.mdx +++ b/apps/docs/content/product/_sdk_v3.mdx @@ -10,9 +10,9 @@ This strategic versioning will ensure a more consistent and intuitive developmen
- Machine User Authentication Methods + Service Account Authentication Methods - This feature introduces robust and standardized authentication methods for your machine users, enabling secure automated access to your resources. + This feature introduces robust and standardized authentication methods for your service accounts, enabling secure automated access to your resources. Choose from the following authentication methods: - **Private Key JWT Authentication**: Enhance security by using asymmetric cryptography. A client with a registered public key can generate and sign a JSON Web Token (JWT) with its private key to authenticate. @@ -26,7 +26,7 @@ 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. + Currently, the client is tailored for machine-to-machine communication, enabling service accounts 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 user authentication flows like OAuth or OIDC.
diff --git a/apps/docs/content/sdk-examples/client-libraries/java.mdx b/apps/docs/content/sdk-examples/client-libraries/java.mdx index c349e3198..641762d01 100644 --- a/apps/docs/content/sdk-examples/client-libraries/java.mdx +++ b/apps/docs/content/sdk-examples/client-libraries/java.mdx @@ -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-accounts/authenticate-service-accounts). +[Zitadel documentation on authenticating service accounts](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts). ### Versioning diff --git a/apps/docs/content/sdk-examples/client-libraries/node.mdx b/apps/docs/content/sdk-examples/client-libraries/node.mdx index 5fb810ded..2aa60568d 100644 --- a/apps/docs/content/sdk-examples/client-libraries/node.mdx +++ b/apps/docs/content/sdk-examples/client-libraries/node.mdx @@ -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-accounts/authenticate-service-accounts). +[Zitadel documentation on authenticating service accounts](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts). ### Versioning diff --git a/apps/docs/content/sdk-examples/client-libraries/php.mdx b/apps/docs/content/sdk-examples/client-libraries/php.mdx index cb7cba127..b47e00b06 100644 --- a/apps/docs/content/sdk-examples/client-libraries/php.mdx +++ b/apps/docs/content/sdk-examples/client-libraries/php.mdx @@ -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-accounts/authenticate-service-accounts). +[Zitadel documentation on authenticating service accounts](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts). ### Versioning diff --git a/apps/docs/content/sdk-examples/client-libraries/python.mdx b/apps/docs/content/sdk-examples/client-libraries/python.mdx index 85e52d950..50897fb7e 100644 --- a/apps/docs/content/sdk-examples/client-libraries/python.mdx +++ b/apps/docs/content/sdk-examples/client-libraries/python.mdx @@ -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-accounts/authenticate-service-accounts). +[Zitadel documentation on authenticating service accounts](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts). ### Versioning diff --git a/apps/docs/content/sdk-examples/client-libraries/ruby.mdx b/apps/docs/content/sdk-examples/client-libraries/ruby.mdx index f0548f65b..f42fe7f6e 100644 --- a/apps/docs/content/sdk-examples/client-libraries/ruby.mdx +++ b/apps/docs/content/sdk-examples/client-libraries/ruby.mdx @@ -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-accounts/authenticate-service-accounts). +[Zitadel documentation on authenticating service accounts](https://zitadel.com/docs/guides/integrate/service-accounts/authenticate-service-accounts). ### Debugging diff --git a/apps/docs/content/sdk-examples/flutter.mdx b/apps/docs/content/sdk-examples/flutter.mdx index 12c85f383..391e1ea75 100644 --- a/apps/docs/content/sdk-examples/flutter.mdx +++ b/apps/docs/content/sdk-examples/flutter.mdx @@ -30,7 +30,7 @@ Check out our [Example Application](/sdk-examples/flutter#example-application). Additionally, you can use [smartive/zitadel-dart](https://github.com/smartive/zitadel-dart) for user and resource management. - Manage Resources through ZITADEL APIs - - Authenticate Service User + - Authenticate Service Account - Generated gRPC Clients for integrating ZITADEL API - User, Organization, Project, etc. Management diff --git a/apps/docs/content/sdk-examples/go.mdx b/apps/docs/content/sdk-examples/go.mdx index 949da8ad3..8174f270a 100644 --- a/apps/docs/content/sdk-examples/go.mdx +++ b/apps/docs/content/sdk-examples/go.mdx @@ -40,7 +40,7 @@ The following features are covered by the SDK: - Authorization Check using OAuth2 Introspection - Check User Roles on Endpoint - Manage Resources through ZITADEL APIs - - Authenticate Service User + - Authenticate Service Account - Generated gRPC Clients for integrating ZITADEL API - User, Organization, Project, etc. Management diff --git a/apps/docs/content/sdk-examples/introduction.mdx b/apps/docs/content/sdk-examples/introduction.mdx index 403eb96b7..a52e784d5 100644 --- a/apps/docs/content/sdk-examples/introduction.mdx +++ b/apps/docs/content/sdk-examples/introduction.mdx @@ -54,7 +54,7 @@ You might want to check out the following links to find a good library: - [B2B customer portal](https://github.com/zitadel/zitadel-nextjs-b2b): Showcase the use of personal access tokens in a B2B environment. Uses Next.js Framework. - [Frontend with backend API](https://github.com/zitadel/example-quote-generator-app): A simple web application using a React front-end and a Python back-end API, both secured using Zitadel -- [Introspection](https://github.com/zitadel/examples-api-access-and-token-introspection): Python examples for securing an API and invoking it as a service user +- [Introspection](https://github.com/zitadel/examples-api-access-and-token-introspection): Python examples for securing an API and invoking it as a service account - [Fine-grained authorization](https://github.com/zitadel/example-fine-grained-authorization): Leverage actions, custom metadata, and claims for attribute-based access control Search for the "example" tag in our repository to [explore all examples](https://github.com/search?q=topic%3Aexamples+org%3Azitadel&type=repositories). diff --git a/apps/docs/content/self-hosting/deploy/kubernetes/configuration.mdx b/apps/docs/content/self-hosting/deploy/kubernetes/configuration.mdx index de5c96694..8744411a8 100644 --- a/apps/docs/content/self-hosting/deploy/kubernetes/configuration.mdx +++ b/apps/docs/content/self-hosting/deploy/kubernetes/configuration.mdx @@ -115,7 +115,7 @@ zitadel: PasswordChangeRequired: false ``` -#### Machine User for System API +#### Service Account for System API For programmatic access, configure a system user with RSA keys: diff --git a/apps/docs/content/self-hosting/manage/login-client.mdx b/apps/docs/content/self-hosting/manage/login-client.mdx index 39887173a..f390ef83b 100644 --- a/apps/docs/content/self-hosting/manage/login-client.mdx +++ b/apps/docs/content/self-hosting/manage/login-client.mdx @@ -14,7 +14,7 @@ In that case, you can create a new PAT for the login client manually. In the following URLs, replace the base URL and the user ID according to your environment. -1. Create a new machine user, for example at http://localhost:8080/ui/console/users/create-machine +1. Create a new service account, for example at http://localhost:8080/ui/console/users/create-machine 2. Create a PAT, for example at http://localhost:8080/ui/console/users/332169800719532035?new=true&id=pat 3. Save the PAT to a file, for example `/path/on/your/host/login-client.pat` 4. Make sure the user has the `Instance Login Client` role (internally called `IAM_LOGIN_CLIENT`), for example at http://localhost:8080/ui/console/instance/members @@ -34,7 +34,7 @@ docker run -p 3000:3000 -v /path/on/your/host/login-client.pat:/path/in/containe Before doing this, make sure you have a working PAT for an instance Owner user. In case something goes wrong and you lock yourself out from the login screen, you can revert the changes. -Create a machine user PAT like you created the [login client PAT above](#create-login-client), but give the user the instance Owner role (internally called `IAM_OWNER`). +Create a service account PAT like you created the [login client PAT above](#create-login-client), but give the user the instance Owner role (internally called `IAM_OWNER`). Enable the `Login V2` feature flag, for example at the bottom of http://localhost:8080/ui/console/instance?id=features. diff --git a/apps/docs/public/img/console_service_user_tokentype.png b/apps/docs/public/img/console_service_account_tokentype.png similarity index 100% rename from apps/docs/public/img/console_service_user_tokentype.png rename to apps/docs/public/img/console_service_account_tokentype.png diff --git a/apps/docs/public/img/console_serviceusers_new_key.gif b/apps/docs/public/img/console_serviceaccounts_new_key.gif similarity index 100% rename from apps/docs/public/img/console_serviceusers_new_key.gif rename to apps/docs/public/img/console_serviceaccounts_new_key.gif diff --git a/apps/docs/public/img/console_serviceusers_secret.gif b/apps/docs/public/img/console_serviceaccounts_secret.gif similarity index 100% rename from apps/docs/public/img/console_serviceusers_secret.gif rename to apps/docs/public/img/console_serviceaccounts_secret.gif diff --git a/apps/docs/public/img/console_serviceusers_create.gif b/apps/docs/public/img/console_serviceusers_create.gif deleted file mode 100644 index bb8704637..000000000 Binary files a/apps/docs/public/img/console_serviceusers_create.gif and /dev/null differ diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/1.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/1.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/1.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/1.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/2.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/2.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/2.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/2.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/3.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/3.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/3.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/3.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/4.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/4.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/4.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/4.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/5.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/5.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/5.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/5.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/6.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/6.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/6.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/6.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/7.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/7.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/7.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/7.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/8.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/8.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/8.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/8.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/9.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/9.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/9.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/9.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/1.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/1.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/1.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/1.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/2.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/2.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/2.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/2.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/3.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/3.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/3.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/3.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/4.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/4.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/4.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/4.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/5.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/5.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/5.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/5.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/6.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/6.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/6.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/6.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/7.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/7.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/7.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/7.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/8.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/8.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/8.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/8.png diff --git a/apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/9.png b/apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/9.png similarity index 100% rename from apps/docs/public/img/examples/secure-api/service-user-jwt/scopes/9.png rename to apps/docs/public/img/examples/secure-api/service-account-jwt/scopes/9.png diff --git a/apps/docs/public/img/guides/integrate/service-users/sequence-private-key-jwt.svg b/apps/docs/public/img/guides/integrate/service-users/sequence-private-key-jwt.svg index e74166a6e..a6e093679 100644 --- a/apps/docs/public/img/guides/integrate/service-users/sequence-private-key-jwt.svg +++ b/apps/docs/public/img/guides/integrate/service-users/sequence-private-key-jwt.svg @@ -1 +1 @@ -Resource Server(API)Authorization Server(ZITADEL)Resource Owner(Client on-behalfof service user)Admin(Manager User)Resource Server(API)Authorization Server(ZITADEL)Resource Owner(Client on-behalfof service user)Admin(Manager User)POST /token HTTP/1.1 ...client_assertion_type=urn:ietf:...:grant-type:jwt-bearerclient_assertion=eyJ....(JWT token)Generate private/public key (API or Management Console)1Store public key2private key3Configure with private key4Generate JWT assertion with private key: payload (sub: serviceUser ID) x private key5Token request with the JWT as Client assertion6validate signature using service user's public key7Provide OAuth access_token8Call API with access_token As Authorization Header9Token introspection10 \ No newline at end of file +Resource Server(API)Authorization Server(ZITADEL)Resource Owner(Client on-behalfof service account)Admin(Manager User)Resource Server(API)Authorization Server(ZITADEL)Resource Owner(Client on-behalfof service account)Admin(Manager User)POST /token HTTP/1.1 ...client_assertion_type=urn:ietf:...:grant-type:jwt-bearerclient_assertion=eyJ....(JWT token)Generate private/public key (API or Management Console)1Store public key2private key3Configure with private key4Generate JWT assertion with private key: payload (sub: serviceUser ID) x private key5Token request with the JWT as Client assertion6validate signature using service account's public key7Provide OAuth access_token8Call API with access_token As Authorization Header9Token introspection10 \ No newline at end of file diff --git a/apps/login/next-env-vars.d.ts b/apps/login/next-env-vars.d.ts index a9370721f..2a5ec1c05 100644 --- a/apps/login/next-env-vars.d.ts +++ b/apps/login/next-env-vars.d.ts @@ -2,12 +2,12 @@ declare namespace NodeJS { interface ProcessEnv { // Allow any environment variable that matches the pattern [key: `${string}_AUDIENCE`]: string; // The system api url - [key: `${string}_SYSTEM_USER_ID`]: string; // The service user id - [key: `${string}_SYSTEM_USER_PRIVATE_KEY`]: string; // The service user private key + [key: `${string}_SYSTEM_USER_ID`]: string; // The service account id + [key: `${string}_SYSTEM_USER_PRIVATE_KEY`]: string; // The service account private key AUDIENCE: string; // The fallback system api url - SYSTEM_USER_ID: string; // The fallback service user id - SYSTEM_USER_PRIVATE_KEY: string; // The fallback service user private key + SYSTEM_USER_ID: string; // The fallback service account id + SYSTEM_USER_PRIVATE_KEY: string; // The fallback service account private key /** * The Zitadel API url @@ -15,7 +15,7 @@ declare namespace NodeJS { ZITADEL_API_URL: string; /** - * The service user token + * The service account token * If ZITADEL_SERVICE_USER_TOKEN is set, its value is used. * If ZITADEL_SERVICE_USER_TOKEN is not set but ZITADEL_SERVICE_USER_TOKEN_FILE is set, the application blocks until the file is created. * As soon as the file exists, its content is read and ZITADEL_SERVICE_USER_TOKEN is set. diff --git a/apps/login/src/lib/deployment.ts b/apps/login/src/lib/deployment.ts index 943a57133..a8fc329b9 100644 --- a/apps/login/src/lib/deployment.ts +++ b/apps/login/src/lib/deployment.ts @@ -15,7 +15,7 @@ export function hasSystemUserCredentials(): boolean { } /** - * Checks if service user token is available for authentication. + * Checks if service account token is available for authentication. * * @returns true if ZITADEL_SERVICE_USER_TOKEN is present, false otherwise */ diff --git a/apps/login/src/lib/service.ts b/apps/login/src/lib/service.ts index 29e56d016..fa7b0c158 100644 --- a/apps/login/src/lib/service.ts +++ b/apps/login/src/lib/service.ts @@ -23,11 +23,11 @@ export async function createServiceForHost(service: T, s let token; // Determine authentication method based on available credentials - // Prefer system user JWT if available, fallback to service user token + // Prefer system user JWT if available, fallback to service account token if (hasSystemUserCredentials()) { token = await systemAPIToken(); } else if (hasServiceUserToken()) { - // Use service user token authentication (self-hosted) + // Use service account token authentication (self-hosted) token = process.env.ZITADEL_SERVICE_USER_TOKEN; } else { throw new Error( diff --git a/backend/v3/domain/user_repo.go b/backend/v3/domain/user_repo.go index abca0af2e..33077e758 100644 --- a/backend/v3/domain/user_repo.go +++ b/backend/v3/domain/user_repo.go @@ -234,8 +234,8 @@ type humanColumns interface { //go:generate mockgen -typed -package domainmock -destination ./mock/machine_user.mock.go . MachineUserRepository type MachineUserRepository interface { - // Update updates the machine user - // It ensures that updates are only applied to machine users + // Update updates the service account + // It ensures that updates are only applied to service accounts Update(ctx context.Context, client database.QueryExecutor, condition database.Condition, changes ...database.Change) (int64, error) machineConditions machineChanges @@ -258,14 +258,14 @@ type machineChanges interface { // SetAccessTokenType sets the personal access token type field SetAccessTokenType(tokenType PersonalAccessTokenType) database.Change - // AddKey adds a key for the machine user + // AddKey adds a key for the service account AddKey(key *MachineKey) database.Change - // RemoveKey removes a key for the machine user + // RemoveKey removes a key for the service account RemoveKey(id string) database.Change - // AddPersonalAccessToken adds a personal access token for the machine user + // AddPersonalAccessToken adds a personal access token for the service account AddPersonalAccessToken(pat *PersonalAccessToken) database.Change - // RemovePersonalAccessToken removes a personal access token for the machine user + // RemovePersonalAccessToken removes a personal access token for the service account RemovePersonalAccessToken(id string) database.Change } diff --git a/benchmark/README.md b/benchmark/README.md index 1289cd75a..1fea50638 100644 --- a/benchmark/README.md +++ b/benchmark/README.md @@ -53,7 +53,7 @@ Before you run the tests you need an initialized user. The tests don't implement setup: creates human users test: creates new sessions with user id check * `make oidc_session` - setup: creates a machine user to create the auth request and session. + setup: creates a service account to create the auth request and session. test: creates an auth request, a session and links the session to the auth request. Implementation of [this flow](https://zitadel.com/docs/guides/integrate/login-ui/oidc-standard). * `make otp_session` setup: creates 1 human user for each VU and adds OTP Email to it @@ -62,10 +62,10 @@ Before you run the tests you need an initialized user. The tests don't implement setup: creates 1 human user for each VU and adds OTP Email to it test: creates a session based on the login name of the user and checks for the password on a second step * `make machine_jwt_profile_grant` - setup: generates private/public key, creates machine users, adds a key + setup: generates private/public key, creates service accounts, adds a key test: creates a token and calls user info * `make machine_jwt_profile_grant_single_user` - setup: generates private/public key, creates machine user, adds a key + setup: generates private/public key, creates service account, adds a key test: creates a token and calls user info in parallel for the same user * `make users_by_metadata_key` setup: creates for half of the VUS a human user and a machine for the other half, adds 3 metadata to each user diff --git a/cmd/defaults.yaml b/cmd/defaults.yaml index 5b3248849..ba89e4538 100644 --- a/cmd/defaults.yaml +++ b/cmd/defaults.yaml @@ -845,7 +845,7 @@ SystemDefaults: # - "scrypt" # - "pbkdf2" # verifier for all pbkdf2 hash modes. SecretHasher: - # Set hasher configuration for machine users, API and OIDC client secrets. + # Set hasher configuration for service accounts, API and OIDC client secrets. Hasher: # Supported algorithms: "argon2i", "argon2id", "bcrypt", "scrypt", "pbkdf2" # Depending on the algorithm, different configuration options take effect. @@ -964,7 +964,7 @@ DefaultInstance: Org: Name: ZITADEL # ZITADEL_DEFAULTINSTANCE_ORG_NAME # In the DefaultInstance.Org.Human section, the initial organization's admin user with the role IAM_OWNER is defined. - # If DefaultInstance.Org.Machine.Machine is defined, a service user is created with the IAM_OWNER role. + # If DefaultInstance.Org.Machine.Machine is defined, a service account is created with the IAM_OWNER role. Human: # In case that UserLoginMustBeDomain is false (default) and if you don't overwrite the username with an email, # it will be suffixed by the org domain (org-name + domain from config). @@ -984,7 +984,7 @@ DefaultInstance: Verified: # ZITADEL_DEFAULTINSTANCE_ORG_HUMAN_PHONE_VERIFIED Password: # ZITADEL_DEFAULTINSTANCE_ORG_HUMAN_PASSWORD # In the DefaultInstance.Org.Machine section, the initial organization's admin user with the role IAM_OWNER is defined. - # If DefaultInstance.Org.Machine.Machine is defined, a service user is created with the IAM_OWNER role. + # If DefaultInstance.Org.Machine.Machine is defined, a service account is created with the IAM_OWNER role. Machine: Machine: Username: # ZITADEL_DEFAULTINSTANCE_ORG_MACHINE_MACHINE_USERNAME diff --git a/cmd/setup/53/02-permitted_orgs_function.sql b/cmd/setup/53/02-permitted_orgs_function.sql index fbc7eaee5..25a8fac19 100644 --- a/cmd/setup/53/02-permitted_orgs_function.sql +++ b/cmd/setup/53/02-permitted_orgs_function.sql @@ -38,7 +38,7 @@ BEGIN RETURN; END IF; - -- if human/machine user + -- if human/service account DECLARE matched_roles TEXT[] := eventstore.find_roles(req_instance_id, perm); BEGIN diff --git a/cmd/setup/53/03-permitted_projects_func.sql b/cmd/setup/53/03-permitted_projects_func.sql index 8c17481ce..3344288cd 100644 --- a/cmd/setup/53/03-permitted_projects_func.sql +++ b/cmd/setup/53/03-permitted_projects_func.sql @@ -29,7 +29,7 @@ BEGIN RETURN; END IF; - -- if human/machine user + -- if human/service account SELECT * FROM eventstore.permitted_orgs( req_instance_id , auth_user_id diff --git a/cmd/setup/steps.yaml b/cmd/setup/steps.yaml index 7b2ab0344..aad283d6c 100644 --- a/cmd/setup/steps.yaml +++ b/cmd/setup/steps.yaml @@ -122,7 +122,7 @@ FirstInstance: Org: Name: ZITADEL # ZITADEL_FIRSTINSTANCE_ORG_NAME # In the FirstInstance.Org.Human section, the initial organization's admin user with the role IAM_OWNER is defined. - # If FirstInstance.Org.Machine.Machine is defined, a service user is created with the IAM_OWNER role. + # If FirstInstance.Org.Machine.Machine is defined, a service account is created with the IAM_OWNER role. Human: # In case UserLoginMustBeDomain is false (default) and you don't overwrite the username with an email, # it will be suffixed by the org domain (org-name + domain from config). @@ -144,7 +144,7 @@ FirstInstance: Password: Password1! # ZITADEL_FIRSTINSTANCE_ORG_HUMAN_PASSWORD PasswordChangeRequired: true # ZITADEL_FIRSTINSTANCE_ORG_HUMAN_PASSWORDCHANGEREQUIRED # In the FirstInstance.Org.Machine section, the initial organization's admin user with the role IAM_OWNER is defined. - # If FirstInstance.Org.Machine.Machine is defined, a service user is created with the IAM_OWNER role. + # If FirstInstance.Org.Machine.Machine is defined, a service account is created with the IAM_OWNER role. Machine: Machine: Username: # ZITADEL_FIRSTINSTANCE_ORG_MACHINE_MACHINE_USERNAME diff --git a/console/src/assets/i18n/ar.json b/console/src/assets/i18n/ar.json index b17029cc1..a2dd40fec 100644 --- a/console/src/assets/i18n/ar.json +++ b/console/src/assets/i18n/ar.json @@ -53,9 +53,9 @@ "METADATA": "أضف سمات مخصصة للمستخدم مثل القسم. يمكنك استخدام هذه المعلومات في إجراءاتك." }, "MACHINES": { - "TITLE": "مستخدمو الخدمة", - "DESCRIPTION": "يقوم مستخدمو الخدمة بالمصادقة بشكل غير تفاعلي باستخدام رمز JWT موقّع بمفتاح خاص. يمكنهم أيضاً استخدام رمز وصول شخصي.", - "METADATA": "أضف سمات مخصصة للمستخدم مثل نظام المصادقة. يمكنك استخدام هذه المعلومات في إجراءاتك." + "TITLE": "حسابات الخدمة", + "DESCRIPTION": "تقوم حسابات الخدمة بالمصادقة بشكل غير تفاعلي باستخدام رمز JWT موقّع بمفتاح خاص. يمكنها أيضاً استخدام رمز وصول شخصي.", + "METADATA": "أضف سمات مخصصة للحساب مثل نظام المصادقة. يمكنك استخدام هذه المعلومات في إجراءاتك." }, "SELF": { "METADATA": "أضف سمات مخصصة للمستخدم الخاص بك مثل قسمك. يمكنك استخدام هذه المعلومات في إجراءات مؤسستك." @@ -424,7 +424,7 @@ "ROLES": "الأدوار", "GRANTEDPROJECT": "المشاريع الممنوحة", "HUMANUSERS": "المستخدمون", - "MACHINEUSERS": "مستخدمو الخدمة", + "MACHINEUSERS": "حسابات الخدمة", "LOGOUT": "تسجيل خروج جميع المستخدمين", "NEWORG": "منظمة جديدة", "IAMADMIN": "أنت مسؤول instance. لاحظ أن لديك أذونات موسعة.", @@ -983,7 +983,7 @@ "COUNTRY": "الدولة" }, "MACHINE": { - "TITLE": "تفاصيل مستخدم الخدمة", + "TITLE": "تفاصيل حساب الخدمة", "USERNAME": "اسم المستخدم", "NAME": "الاسم", "DESCRIPTION": "الوصف", @@ -1145,7 +1145,7 @@ "SELECTEDDEACTIVATED": "تم تعطيل المستخدمين المحددين.", "SELECTEDKEYSDELETED": "تم حذف المفاتيح المحددة.", "KEYADDED": "تمت إضافة المفتاح!", - "MACHINEADDED": "تم إنشاء مستخدم الخدمة!", + "MACHINEADDED": "تم إنشاء حساب الخدمة!", "DELETED": "تم حذف المستخدم بنجاح!", "UNLOCKED": "تم فتح قفل المستخدم بنجاح!", "PASSWORDLESSREGISTRATIONSENT": "تم إرسال رابط التسجيل بنجاح.", diff --git a/console/src/assets/i18n/bg.json b/console/src/assets/i18n/bg.json index d04c0a058..6bd6d99ad 100644 --- a/console/src/assets/i18n/bg.json +++ b/console/src/assets/i18n/bg.json @@ -53,9 +53,9 @@ "METADATA": "Добавете персонализирани атрибути към потребителя, като отдела. Можете да използвате тази информация във вашите действия." }, "MACHINES": { - "TITLE": "потребители на услугата", - "DESCRIPTION": "Потребителите на услугата се удостоверяват неинтерактивно, като използват JWT носител, подписан с частен ключ. Те могат също да използват личен маркер за достъп.", - "METADATA": "Добавете персонализирани атрибути към потребителя, като системата за удостоверяване. Можете да използвате тази информация във вашите действия." + "TITLE": "сметки на услугата", + "DESCRIPTION": "Сметките на услугата се удостоверяват неинтерактивно, като използват JWT носител, подписан с частен ключ. Те могат също да използват личен маркер за достъп.", + "METADATA": "Добавете персонализирани атрибути към сметката, като системата за удостоверяване. Можете да използвате тази информация във вашите действия." }, "SELF": { "METADATA": "Добавете персонализирани атрибути към вашия потребител, като вашето отделение. Можете да използвате тази информация в действията на вашите организации." @@ -424,7 +424,7 @@ "ROLES": "Роли", "GRANTEDPROJECT": "Предоставени проекти", "HUMANUSERS": "Потребители", - "MACHINEUSERS": "Потребители на услугата", + "MACHINEUSERS": "Сметки на услугата", "LOGOUT": "Излезте всички потребители", "NEWORG": "Нова организация", "IAMADMIN": "Вие сте инстанс администратор. ", @@ -989,7 +989,7 @@ "COUNTRY": "Държава" }, "MACHINE": { - "TITLE": "Подробности за потребителя на услугата", + "TITLE": "Подробности за сметката на услугата", "USERNAME": "Потребителско име", "NAME": "Име", "DESCRIPTION": "Описание", @@ -1151,7 +1151,7 @@ "SELECTEDDEACTIVATED": "Избраните потребители са деактивирани.", "SELECTEDKEYSDELETED": "Избраните ключове са изтрити.", "KEYADDED": "Ключът е добавен!", - "MACHINEADDED": "Потребител на услугата е създаден!", + "MACHINEADDED": "Сметката на услугата е създадена!", "DELETED": "Потребителят е изтрит успешно!", "UNLOCKED": "Потребителят е отключен успешно!", "PASSWORDLESSREGISTRATIONSENT": "Линкът за регистрация е изпратен успешно.", diff --git a/console/src/assets/i18n/cs.json b/console/src/assets/i18n/cs.json index bb52cd33e..95cbb8432 100644 --- a/console/src/assets/i18n/cs.json +++ b/console/src/assets/i18n/cs.json @@ -53,9 +53,9 @@ "METADATA": "Přidejte vlastní atributy k uživateli, jako je oddělení. Tyto informace můžete využít ve vašich akcích." }, "MACHINES": { - "TITLE": "Uživatelé služby", - "DESCRIPTION": "Uživatelé služby se ověřují neinteraktivně pomocí tokenu nosiče JWT podepsaného soukromým klíčem. Mohou také použít osobní přístupový token.", - "METADATA": "Přidejte vlastní atributy k uživateli, jako je autentizační systém. Tyto informace můžete využít ve vašich akcích." + "TITLE": "Servisní účty", + "DESCRIPTION": "Servisní účty se ověřují neinteraktivně pomocí tokenu nosiče JWT podepsaného soukromým klíčem. Mohou také použít osobní přístupový token.", + "METADATA": "Přidejte vlastní atributy k účtu, jako je autentizační systém. Tyto informace můžete využít ve vašich akcích." }, "SELF": { "METADATA": "Přidejte vlastní atributy k vašemu uživateli, jako je vaše oddělení. Tyto informace můžete využít v akcích vaší organizace." @@ -424,7 +424,7 @@ "ROLES": "Role", "GRANTEDPROJECT": "Pověřené projekty", "HUMANUSERS": "Uživatelé", - "MACHINEUSERS": "Systémoví uživatelé", + "MACHINEUSERS": "Servisní účty", "LOGOUT": "Odhlásit všechny uživatele", "NEWORG": "Nová organizace", "IAMADMIN": "Jste administrátor instance. Vezměte prosím na vědomí, že máte rozšířená oprávnění.", @@ -990,7 +990,7 @@ "COUNTRY": "Země" }, "MACHINE": { - "TITLE": "Detaily systémového uživatele", + "TITLE": "Detaily servisního účtu", "USERNAME": "Uživatelské jméno", "NAME": "Název", "DESCRIPTION": "Popis", diff --git a/console/src/assets/i18n/de.json b/console/src/assets/i18n/de.json index 100456f50..d1b035831 100644 --- a/console/src/assets/i18n/de.json +++ b/console/src/assets/i18n/de.json @@ -53,9 +53,9 @@ "METADATA": "Füge dem Benutzer benutzerdefinierte Attribute hinzu, wie die Abteilung. Du kannst diese Informationen in den Aktionen nutzen." }, "MACHINES": { - "TITLE": "Service-Benutzer", - "DESCRIPTION": "Service-Benutzer authentifizieren sich nicht-interaktiv mit einem JWT Bearer-Token, welches mit einem privaten Schlüssel signiert ist. Sie können auch ein persönliches Zugangstoken verwenden.", - "METADATA": "Füge dem Benutzer benutzerdefinierte Attribute hinzu, wie das authentifizierende System. Du kannst diese Informationen in den Aktionen nutzen." + "TITLE": "Servicekonten", + "DESCRIPTION": "Servicekonten authentifizieren sich nicht-interaktiv mit einem JWT Bearer-Token, welches mit einem privaten Schlüssel signiert ist. Sie können auch ein persönliches Zugangstoken verwenden.", + "METADATA": "Füge dem Konto benutzerdefinierte Attribute hinzu, wie das authentifizierende System. Du kannst diese Informationen in den Aktionen nutzen." }, "SELF": { "METADATA": "Füge deinem Benutzer benutzerdefinierte Attribute hinzu, wie deine Abteilung. Du kannst diese Informationen in den Aktionen deiner Organisation nutzen." @@ -424,7 +424,7 @@ "ROLES": "Rollen", "GRANTEDPROJECT": "Berechtigte Projekte", "HUMANUSERS": "Benutzer", - "MACHINEUSERS": "Service-Benutzer", + "MACHINEUSERS": "Servicekonten", "LOGOUT": "Alle Benutzer abmelden", "NEWORG": "Neue Organisation", "IAMADMIN": "Du bist ein Instanz-Administrator. Beachte, dass Du erhöhte Rechte besitzt.", @@ -990,8 +990,8 @@ "COUNTRY": "Land" }, "MACHINE": { - "TITLE": "Details Service-Benutzer", - "USERNAME": "Benutzername", + "TITLE": "Details Servicekonto", + "USERNAME": "Kontoname", "NAME": "Name", "DESCRIPTION": "Beschreibung", "KEYSTITLE": "Schlüssel", @@ -1152,7 +1152,7 @@ "SELECTEDDEACTIVATED": "Selektierte Benutzer deaktiviert.", "SELECTEDKEYSDELETED": "Selektierte Schlüssel gelöscht.", "KEYADDED": "Schlüssel hinzugefügt!", - "MACHINEADDED": "Service-Benutzer erstellt!", + "MACHINEADDED": "Servicekonto erstellt!", "DELETED": "Benutzer erfolgreich gelöscht!", "UNLOCKED": "Benutzer erfolgreich freigeschaltet!", "PASSWORDLESSREGISTRATIONSENT": "Passkey Registrierungslink via E-Mail versendet.", diff --git a/console/src/assets/i18n/en.json b/console/src/assets/i18n/en.json index 91a0b6296..2eb3af058 100644 --- a/console/src/assets/i18n/en.json +++ b/console/src/assets/i18n/en.json @@ -53,9 +53,9 @@ "METADATA": "Add custom attributes to the user like the department. You can use this information in your actions." }, "MACHINES": { - "TITLE": "Service Users", - "DESCRIPTION": "Service Users authenticate non-interactively using a JWT bearer token signed with a private key. They can also use a personal access token.", - "METADATA": "Add custom attributes to the user like the authenticating system. You can use this information in your actions." + "TITLE": "Service Accounts", + "DESCRIPTION": "Service Accounts authenticate non-interactively using a JWT bearer token signed with a private key. They can also use a personal access token.", + "METADATA": "Add custom attributes to the account like the authenticating system. You can use this information in your actions." }, "SELF": { "METADATA": "Add custom attributes to your user like your department. You can use this information in your organizations actions." @@ -424,7 +424,7 @@ "ROLES": "Roles", "GRANTEDPROJECT": "Granted Projects", "HUMANUSERS": "Users", - "MACHINEUSERS": "Service Users", + "MACHINEUSERS": "Service Accounts", "LOGOUT": "Logout All Users", "NEWORG": "New Organization", "IAMADMIN": "You are an IAM Administrator. Note that you have extended permissions.", @@ -991,7 +991,7 @@ "COUNTRY": "Country" }, "MACHINE": { - "TITLE": "Service User Details", + "TITLE": "Service Account Details", "USERNAME": "User Name", "NAME": "Name", "DESCRIPTION": "Description", @@ -1153,7 +1153,7 @@ "SELECTEDDEACTIVATED": "Selected users deactivated.", "SELECTEDKEYSDELETED": "Selected keys deleted.", "KEYADDED": "Key added!", - "MACHINEADDED": "Service User created!", + "MACHINEADDED": "Service Account created!", "DELETED": "User deleted successfully!", "UNLOCKED": "User unlocked successfully!", "PASSWORDLESSREGISTRATIONSENT": "Registration Link sent successfully.", diff --git a/console/src/assets/i18n/es.json b/console/src/assets/i18n/es.json index af7618cfc..b642570ea 100644 --- a/console/src/assets/i18n/es.json +++ b/console/src/assets/i18n/es.json @@ -53,9 +53,9 @@ "METADATA": "Añade atributos personalizados al usuario como el departamento. Puedes usar esta información en tus acciones." }, "MACHINES": { - "TITLE": "Usuarios del servicio", - "DESCRIPTION": "Los Usuarios del servicio se autentican de manera no interactiva usando un token portador JWT firmado con una clave privada. También pueden usar un token de acceso personal.", - "METADATA": "Añade atributos personalizados al usuario como el sistema autenticador. Puedes usar esta información en tus acciones." + "TITLE": "Cuentas de servicio", + "DESCRIPTION": "Las cuentas de servicio se autentican de manera no interactiva usando un token portador JWT firmado con una clave privada. También pueden usar un token de acceso personal.", + "METADATA": "Añade atributos personalizados a la cuenta como el sistema autenticador. Puedes usar esta información en tus acciones." }, "SELF": { "METADATA": "Añade atributos personalizados a tu usuario como tu departamento. Puedes usar esta información en las acciones de tu organización." @@ -424,7 +424,7 @@ "ROLES": "Roles", "GRANTEDPROJECT": "Proyecto concedido", "HUMANUSERS": "Usuarios", - "MACHINEUSERS": "Usuarios del servicio", + "MACHINEUSERS": "Cuentas de servicio", "LOGOUT": "Cerrar sesión para todos los usuarios", "NEWORG": "Nueva organización", "IAMADMIN": "Eres un administrador instancia. Ten en cuenta que tienes permisos ampliados.", @@ -990,8 +990,8 @@ "COUNTRY": "País" }, "MACHINE": { - "TITLE": "Detalles del usuario del servicio", - "USERNAME": "Nombre de usuario", + "TITLE": "Detalles de la cuenta de servicio", + "USERNAME": "Nombre de la cuenta", "NAME": "Nombre", "DESCRIPTION": "Descripción", "KEYSTITLE": "Claves", @@ -1152,7 +1152,7 @@ "SELECTEDDEACTIVATED": "Se desactivaron los usuarios seleccionados.", "SELECTEDKEYSDELETED": "Se borraron las claves seleccionadas.", "KEYADDED": "¡Clave añadida!", - "MACHINEADDED": "¡Creado servicio de usuario!", + "MACHINEADDED": "¡Cuenta de servicio creada!", "DELETED": "¡El usuario se borró con éxito!", "UNLOCKED": "¡El usuario se desbloqueó con éxito!", "PASSWORDLESSREGISTRATIONSENT": "Enviado con éxito un enlace de registro.", diff --git a/console/src/assets/i18n/fr.json b/console/src/assets/i18n/fr.json index 1a738fc8f..a49a85a60 100644 --- a/console/src/assets/i18n/fr.json +++ b/console/src/assets/i18n/fr.json @@ -53,9 +53,9 @@ "METADATA": "Ajoutez des attributs personnalisés à l'utilisateur comme le département. Vous pouvez utiliser cette information dans vos actions." }, "MACHINES": { - "TITLE": "Utilisateurs des services", - "DESCRIPTION": "Les utilisateurs des services s'authentifient de manière non interactive en utilisant un token porteur JWT signé avec une clé privée. Elles peuvent également utiliser un token d'accès personnel.", - "METADATA": "Ajoute des attributs personnalisés à l'utilisateur comme le système d'authentification. Vous pouvez utiliser cette information dans vos actions." + "TITLE": "Comptes de service", + "DESCRIPTION": "Les comptes de service s'authentifient de manière non interactive en utilisant un token porteur JWT signé avec une clé privée. Elles peuvent également utiliser un token d'accès personnel.", + "METADATA": "Ajoute des attributs personnalisés au compte comme le système d'authentification. Vous pouvez utiliser cette information dans vos actions." }, "SELF": { "METADATA": "Ajoutez des attributs personnalisés à votre utilisateur comme votre département. Vous pouvez utiliser cette information dans les actions de votre organisation." @@ -424,7 +424,7 @@ "ROLES": "Rôles", "GRANTEDPROJECT": "Projets octroyés", "HUMANUSERS": "Utilisateurs", - "MACHINEUSERS": "Utilisateurs de services", + "MACHINEUSERS": "Comptes de service", "LOGOUT": "Déconnexion de tous les utilisateurs", "NEWORG": "Nouvelle organisation", "IAMADMIN": "Vous êtes un administrateur d'instance. Notez que vous disposez de permissions étendues.", @@ -990,8 +990,8 @@ "COUNTRY": "Pays" }, "MACHINE": { - "TITLE": "Détails de l'utilisateur du service", - "USERNAME": "Nom de l'utilisateur", + "TITLE": "Détails du compte de service", + "USERNAME": "Nom du compte", "NAME": "Nom", "DESCRIPTION": "Description", "KEYSTITLE": "Clés", @@ -1152,7 +1152,7 @@ "SELECTEDDEACTIVATED": "Utilisateurs sélectionnés désactivés.", "SELECTEDKEYSDELETED": "Clés sélectionnées supprimées.", "KEYADDED": "Clé ajoutée !", - "MACHINEADDED": "Utilisateur de service créé !", + "MACHINEADDED": "Compte de service créé !", "DELETED": "Utilisateur supprimé avec succès !", "UNLOCKED": "Utilisateur déverrouillé avec succès !", "PASSWORDLESSREGISTRATIONSENT": "Lien d'enregistrement envoyé avec succès.", diff --git a/console/src/assets/i18n/hu.json b/console/src/assets/i18n/hu.json index bc0186def..4cdcfb645 100644 --- a/console/src/assets/i18n/hu.json +++ b/console/src/assets/i18n/hu.json @@ -53,9 +53,9 @@ "METADATA": "Adj hozzá egyéni attribútumokat a felhasználóhoz, mint például az osztály. Ezt az információt felhasználhatod a műveleteid során." }, "MACHINES": { - "TITLE": "Szolgáltatásfelhasználók", - "DESCRIPTION": "A szolgáltatásfelhasználók nem interaktívan hitelesítik magukat egy privát kulccsal aláírt JWT hordozó tokennel. Személyes hozzáférési tokent is használhatnak.", - "METADATA": "Adj hozzá egyéni attribútumokat a felhasználóhoz, mint például a hitelesítő rendszer. Ezt az információt felhasználhatod a műveleteid során." + "TITLE": "Szolgáltatásfiók", + "DESCRIPTION": "A szolgáltatásfiókok nem interaktívan hitelesítik magukat egy privát kulccsal aláírt JWT hordozó tokennel. Személyes hozzáférési tokent is használhatnak.", + "METADATA": "Adj hozzá egyéni attribútumokat a fiókhoz, mint például a hitelesítő rendszer. Ezt az információt felhasználhatod a műveleteid során." }, "SELF": { "METADATA": "Adj hozzá egyéni attribútumokat a felhasználódhoz, mint például az osztályod. Ezt az információt felhasználhatod a szervezeted műveleteiben." @@ -424,7 +424,7 @@ "ROLES": "Szerepkörök", "GRANTEDPROJECT": "Megadott Projektek", "HUMANUSERS": "Felhasználók", - "MACHINEUSERS": "Szolgáltatási Felhasználók", + "MACHINEUSERS": "Szolgáltatásfiók", "LOGOUT": "Minden Felhasználó Kijelentkezése", "NEWORG": "Új Szervezet", "IAMADMIN": "Te egy példány Adminisztrátor vagy. Ne felejtsd el, hogy kibővített jogosultságokkal rendelkezel.", @@ -1152,7 +1152,7 @@ "SELECTEDDEACTIVATED": "A kiválasztott felhasználók deaktiválva.", "SELECTEDKEYSDELETED": "A kiválasztott kulcsok törölve.", "KEYADDED": "Kulcs hozzáadva!", - "MACHINEADDED": "Service User létrehozva!", + "MACHINEADDED": "Szolgáltatásfiók létrehozva!", "DELETED": "A felhasználó sikeresen törölve!", "UNLOCKED": "A felhasználó sikeresen feloldva!", "PASSWORDLESSREGISTRATIONSENT": "A Passkey regisztrációs link sikeresen elküldve.", diff --git a/console/src/assets/i18n/id.json b/console/src/assets/i18n/id.json index f94ef480d..53f257ce6 100644 --- a/console/src/assets/i18n/id.json +++ b/console/src/assets/i18n/id.json @@ -53,8 +53,8 @@ "METADATA": "Tambahkan atribut khusus ke pengguna seperti departemen. Anda dapat menggunakan informasi ini dalam tindakan Anda." }, "MACHINES": { - "TITLE": "Pengguna Layanan", - "DESCRIPTION": "Pengguna Layanan mengautentikasi secara non-interaktif menggunakan token pembawa JWT yang ditandatangani dengan kunci pribadi. Mereka juga dapat menggunakan token akses pribadi.", + "TITLE": "Akun Layanan", + "DESCRIPTION": "Akun Layanan mengautentikasi secara non-interaktif menggunakan token pembawa JWT yang ditandatangani dengan kunci pribadi. Mereka juga dapat menggunakan token akses pribadi.", "METADATA": "Tambahkan atribut khusus kepada pengguna seperti sistem autentikasi. Anda dapat menggunakan informasi ini dalam tindakan Anda." }, "SELF": { @@ -424,7 +424,7 @@ "ROLES": "Peran", "GRANTEDPROJECT": "Proyek yang Diberikan", "HUMANUSERS": "Pengguna", - "MACHINEUSERS": "Pengguna Layanan", + "MACHINEUSERS": "Akun Layanan", "LOGOUT": "Logout Semua Pengguna", "NEWORG": "Organisasi Baru", "IAMADMIN": "Anda adalah Administrator instance. Perhatikan bahwa Anda memiliki izin yang diperluas.", @@ -990,7 +990,7 @@ "COUNTRY": "Negara" }, "MACHINE": { - "TITLE": "Detail Pengguna Layanan", + "TITLE": "Detail Akun Layanan", "USERNAME": "Nama belakang", "NAME": "Nama", "DESCRIPTION": "Keterangan", @@ -1152,7 +1152,7 @@ "SELECTEDDEACTIVATED": "Pengguna terpilih dinonaktifkan.", "SELECTEDKEYSDELETED": "Kunci yang dipilih dihapus.", "KEYADDED": "Kunci ditambahkan!", - "MACHINEADDED": "Pengguna Layanan dibuat!", + "MACHINEADDED": "Akun Layanan dibuat!", "DELETED": "Pengguna berhasil dihapus!", "UNLOCKED": "Pengguna berhasil membuka kuncinya!", "PASSWORDLESSREGISTRATIONSENT": "Tautan Pendaftaran berhasil dikirim.", diff --git a/console/src/assets/i18n/it.json b/console/src/assets/i18n/it.json index e1926558a..7fa07d218 100644 --- a/console/src/assets/i18n/it.json +++ b/console/src/assets/i18n/it.json @@ -53,9 +53,9 @@ "METADATA": "Aggiungi attributi personalizzati all'utente come il dipartimento. Puoi utilizzare queste informazioni nelle tue azioni." }, "MACHINES": { - "TITLE": "Utenti di servizio", - "DESCRIPTION": "Utenti di servizio si autenticano in modo non interattivo utilizzando un token JWT firmato con una chiave privata. Possono anche utilizzare un token di accesso personale.", - "METADATA": "Aggiungi attributi personalizzati all'utente come il sistema di autenticazione. Puoi utilizzare queste informazioni nelle tue azioni." + "TITLE": "Account di servizio", + "DESCRIPTION": "Gli account di servizio si autenticano in modo non interattivo utilizzando un token JWT firmato con una chiave privata. Possono anche utilizzare un token di accesso personale.", + "METADATA": "Aggiungi attributi personalizzati all'account come il sistema di autenticazione. Puoi utilizzare queste informazioni nelle tue azioni." }, "SELF": { "METADATA": "Aggiungi attributi personalizzati al tuo utente come il tuo dipartimento. Puoi utilizzare queste informazioni nelle azioni della tua organizzazione." @@ -424,7 +424,7 @@ "ROLES": "Ruoli", "GRANTEDPROJECT": "Progetto delegato", "HUMANUSERS": "Utenti", - "MACHINEUSERS": "Utenti di servizio", + "MACHINEUSERS": "Account di servizio", "LOGOUT": "Esci con tutti gli utenti", "NEWORG": "Nuova organizzazione", "IAMADMIN": "Sei un amministratore d'istanza. Nota che hai autorizzazioni estese.", @@ -989,8 +989,8 @@ "COUNTRY": "Paese" }, "MACHINE": { - "TITLE": "Dettagli dell'utente del servizio", - "USERNAME": "Nome utente", + "TITLE": "Dettagli dell'account di servizio", + "USERNAME": "Nome dell'account", "NAME": "Nome", "DESCRIPTION": "Descrizione", "KEYSTITLE": "Chiavi", @@ -1151,7 +1151,7 @@ "SELECTEDDEACTIVATED": "Utenti selezionati disattivati.", "SELECTEDKEYSDELETED": "Tasti selezionati cancellati.", "KEYADDED": "Chiave aggiunta!", - "MACHINEADDED": "Utente di servizio creato!", + "MACHINEADDED": "Account di servizio creato!", "DELETED": "Utente cancellato con successo!", "UNLOCKED": "Utente sbloccato con successo!", "PASSWORDLESSREGISTRATIONSENT": "Link per la registrazione inviato con successo.", diff --git a/console/src/assets/i18n/ja.json b/console/src/assets/i18n/ja.json index bc7632af4..5002ed235 100644 --- a/console/src/assets/i18n/ja.json +++ b/console/src/assets/i18n/ja.json @@ -53,9 +53,9 @@ "METADATA": "部門のようなユーザーにカスタム属性を追加してください。この情報をあなたのアクションで使用できます。" }, "MACHINES": { - "TITLE": "サービス利用者", - "DESCRIPTION": "サービス ユーザーは、秘密キーで署名された JWT ベアラー トークンを使用して非対話的に認証されます。個人のアクセス トークンを使用することもできます。", - "METADATA": "認証システムのようなユーザーにカスタム属性を追加してください。この情報をあなたのアクションで使用できます。" + "TITLE": "サービスアカウント", + "DESCRIPTION": "サービスアカウントは、秘密キーで署名された JWT ベアラー トークンを使用して非対話的に認証されます。個人のアクセス トークンを使用することもできます。", + "METADATA": "認証システムのようなアカウントにカスタム属性を追加してください。この情報をあなたのアクションで使用できます。" }, "SELF": { "METADATA": "あなたの部門のようなあなたのユーザーにカスタム属性を追加してください。この情報をあなたの組織のアクションで使用できます。" @@ -424,7 +424,7 @@ "ROLES": "ロール", "GRANTEDPROJECT": "グラントされたプロジェクト", "HUMANUSERS": "ユーザー", - "MACHINEUSERS": "サービスユーザー", + "MACHINEUSERS": "サービスアカウント", "LOGOUT": "すべてのユーザーをログアウトする", "NEWORG": "新しい組織", "IAMADMIN": "あなたはインスタンス管理者です。広範囲の権限があることに注意してください。", @@ -990,8 +990,8 @@ "COUNTRY": "国" }, "MACHINE": { - "TITLE": "サービスユーザーの詳細", - "USERNAME": "ユーザー名", + "TITLE": "サービスアカウントの詳細", + "USERNAME": "アカウント名", "NAME": "名前", "DESCRIPTION": "概要", "KEYSTITLE": "キー", @@ -1152,7 +1152,7 @@ "SELECTEDDEACTIVATED": "選択されたユーザー非アクティブになりました。", "SELECTEDKEYSDELETED": "選択したキーが削除されました。", "KEYADDED": "キーが追加されました！", - "MACHINEADDED": "サービスユーザーが作成されました！", + "MACHINEADDED": "サービスアカウントが作成されました！", "DELETED": "ユーザーが正常に削除されました！", "UNLOCKED": "ユーザーのロックが正常に解除されました！", "PASSWORDLESSREGISTRATIONSENT": "登録リンクが正常に送信されました。", diff --git a/console/src/assets/i18n/ko.json b/console/src/assets/i18n/ko.json index c2272ba9a..88ca69239 100644 --- a/console/src/assets/i18n/ko.json +++ b/console/src/assets/i18n/ko.json @@ -53,8 +53,8 @@ "METADATA": "부서와 같은 사용자 정의 속성을 사용자에게 추가하세요. 이 정보를 작업에 사용할 수 있습니다." }, "MACHINES": { - "TITLE": "서비스 사용자", - "DESCRIPTION": "서비스 사용자는 개인 키로 서명된 JWT bearer 토큰을 사용하여 비대화형 인증을 수행합니다. 또한 개인 액세스 토큰을 사용할 수 있습니다.", + "TITLE": "서비스 계정", + "DESCRIPTION": "서비스 계정은 개인 키로 서명된 JWT bearer 토큰을 사용하여 비대화형 인증을 수행합니다. 또한 개인 액세스 토큰을 사용할 수 있습니다.", "METADATA": "인증 시스템과 같은 사용자 정의 속성을 사용자에게 추가하세요. 이 정보를 작업에 사용할 수 있습니다." }, "SELF": { @@ -424,7 +424,7 @@ "ROLES": "역할", "GRANTEDPROJECT": "부여된 프로젝트", "HUMANUSERS": "사용자", - "MACHINEUSERS": "서비스 사용자", + "MACHINEUSERS": "서비스 계정", "LOGOUT": "모든 사용자 로그아웃", "NEWORG": "새 조직", "IAMADMIN": "인스턴스 관리자입니다. 확장된 권한이 부여되었습니다.", diff --git a/console/src/assets/i18n/mk.json b/console/src/assets/i18n/mk.json index c460ea2af..c406f8deb 100644 --- a/console/src/assets/i18n/mk.json +++ b/console/src/assets/i18n/mk.json @@ -53,8 +53,8 @@ "METADATA": "Додади прилагодени атрибути на корисникот како оддел. Можеш да ги користиш овие информации во твоите активности." }, "MACHINES": { - "TITLE": "Корисници на услуги", - "DESCRIPTION": "Корисниците на услугата неинтерактивно ја автентицираат користејќи токен на носител JWT потпишан со приватен клуч. Тие исто така можат да користат токен за личен пристап.", + "TITLE": "Сметки на услугата", + "DESCRIPTION": "Сметките на услугата неинтерактивно ја автентицираат користејќи токен на носител JWT потпишан со приватен клуч. Тие исто така можат да користат токен за личен пристап.", "METADATA": "Додади прилагодени атрибути на корисникот како систем за автентикација. Можеш да ги користиш овие информации во твоите активности." }, "SELF": { @@ -424,7 +424,7 @@ "ROLES": "Улоги", "GRANTEDPROJECT": "Доделени проекти", "HUMANUSERS": "Корисници", - "MACHINEUSERS": "Сервисни корисници", + "MACHINEUSERS": "Сметки на услугата", "LOGOUT": "Одјави ги сите корисници", "NEWORG": "Нова организација", "IAMADMIN": "Вие сте администратор на инстанс. Имате проширени овластувања.", diff --git a/console/src/assets/i18n/nl.json b/console/src/assets/i18n/nl.json index e5939d8ef..ef09f5d71 100644 --- a/console/src/assets/i18n/nl.json +++ b/console/src/assets/i18n/nl.json @@ -53,9 +53,9 @@ "METADATA": "Voeg aangepaste attributen toe aan de gebruiker zoals de afdeling. Je kunt deze informatie gebruiken in je acties." }, "MACHINES": { - "TITLE": "Servicegebruikers", - "DESCRIPTION": "Servicegebruikers authenticeren niet-interactief met behulp van een JWT-bearertoken ondertekend met een privésleutel. Ze kunnen ook een persoonlijk toegangstoken gebruiken.", - "METADATA": "Voeg aangepaste attributen toe aan de gebruiker zoals het authenticatiesysteem. Je kunt deze informatie gebruiken in je acties." + "TITLE": "Serviceaccounts", + "DESCRIPTION": "Serviceaccounts authenticeren niet-interactief met behulp van een JWT-bearertoken ondertekend met een privésleutel. Ze kunnen ook een persoonlijk toegangstoken gebruiken.", + "METADATA": "Voeg aangepaste attributen toe aan het account zoals het authenticatiesysteem. Je kunt deze informatie gebruiken in je acties." }, "SELF": { "METADATA": "Voeg aangepaste attributen toe aan je gebruiker zoals je afdeling. Je kunt deze informatie gebruiken in de acties van je organisatie." @@ -424,7 +424,7 @@ "ROLES": "Rollen", "GRANTEDPROJECT": "Verleende projecten", "HUMANUSERS": "Gebruikers", - "MACHINEUSERS": "Servicegebruikers", + "MACHINEUSERS": "Serviceaccounts", "LOGOUT": "Alle gebruikers uitloggen", "NEWORG": "Nieuwe organisatie", "IAMADMIN": "U bent een instantie-beheerder. Let op: u heeft uitgebreide rechten.", @@ -990,8 +990,8 @@ "COUNTRY": "Land" }, "MACHINE": { - "TITLE": "Details Servicegebruiker", - "USERNAME": "Gebruikersnaam", + "TITLE": "Details Serviceaccount", + "USERNAME": "Accountnaam", "NAME": "Naam", "DESCRIPTION": "Beschrijving", "KEYSTITLE": "Sleutels", @@ -1152,7 +1152,7 @@ "SELECTEDDEACTIVATED": "Geselecteerde gebruikers gedeactiveerd.", "SELECTEDKEYSDELETED": "Geselecteerde sleutels verwijderd.", "KEYADDED": "Sleutel toegevoegd!", - "MACHINEADDED": "Servicegebruiker aangemaakt!", + "MACHINEADDED": "Serviceaccount aangemaakt!", "DELETED": "Gebruiker succesvol verwijderd!", "UNLOCKED": "Gebruiker succesvol ontgrendeld!", "PASSWORDLESSREGISTRATIONSENT": "Registratielink succesvol verzonden.", diff --git a/console/src/assets/i18n/pl.json b/console/src/assets/i18n/pl.json index a65699ab5..f3320e422 100644 --- a/console/src/assets/i18n/pl.json +++ b/console/src/assets/i18n/pl.json @@ -53,9 +53,9 @@ "METADATA": "Dodaj niestandardowe atrybuty do użytkownika, takie jak dział. Możesz użyć tych informacji w swoich działaniach." }, "MACHINES": { - "TITLE": "Użytkownicy serwisu", - "DESCRIPTION": "Użytkownicy usługi uwierzytelniają się w sposób nieinteraktywny przy użyciu tokena okaziciela JWT podpisanego kluczem prywatnym. Mogą także skorzystać z osobistego tokena dostępu.", - "METADATA": "Dodaj niestandardowe atrybuty do użytkownika, takie jak system uwierzytelniający. Możesz użyć tych informacji w swoich działaniach." + "TITLE": "Konta serwisu", + "DESCRIPTION": "Konta serwisu uwierzytelniają się w sposób nieinteraktywny przy użyciu tokena okaziciela JWT podpisanego kluczem prywatnym. Mogą także skorzystać z osobistego tokena dostępu.", + "METADATA": "Dodaj niestandardowe atrybuty do konta, takie jak system uwierzytelniający. Możesz użyć tych informacji w swoich działaniach." }, "SELF": { "METADATA": "Dodaj niestandardowe atrybuty do siebie, takie jak twój dział. Możesz użyć tych informacji w działaniach swojej organizacji." @@ -424,7 +424,7 @@ "ROLES": "Role", "GRANTEDPROJECT": "Uprawnione projekty", "HUMANUSERS": "Użytkownicy", - "MACHINEUSERS": "Użytkownicy usług", + "MACHINEUSERS": "Konta serwisu", "LOGOUT": "Wyloguj Wszystkich Użytkowników", "NEWORG": "Nowa Organizacja", "IAMADMIN": "Jesteś administratorem instancja. Zauważ, że masz rozszerzone uprawnienia.", diff --git a/console/src/assets/i18n/pt.json b/console/src/assets/i18n/pt.json index 5c882f879..097c3fdfe 100644 --- a/console/src/assets/i18n/pt.json +++ b/console/src/assets/i18n/pt.json @@ -53,9 +53,9 @@ "METADATA": "Adicione atributos personalizados ao usuário, como o departamento. Você pode usar essas informações em suas ações." }, "MACHINES": { - "TITLE": "Usuários do serviço", - "DESCRIPTION": "Os usuários do serviço autenticam-se de forma não interativa usando um token de portador JWT assinado com uma chave privada. Eles também podem usar um token de acesso pessoal.", - "METADATA": "Adicione atributos personalizados ao usuário, como o sistema de autenticação. Você pode usar essas informações em suas ações." + "TITLE": "Contas de serviço", + "DESCRIPTION": "As contas de serviço autenticam-se de forma não interativa usando um token de portador JWT assinado com uma chave privada. Elas também podem usar um token de acesso pessoal.", + "METADATA": "Adicione atributos personalizados à conta, como o sistema de autenticação. Você pode usar essas informações em suas ações." }, "SELF": { "METADATA": "Adicione atributos personalizados ao seu usuário, como seu departamento. Você pode usar essas informações nas ações da sua organização." @@ -424,7 +424,7 @@ "ROLES": "Funções", "GRANTEDPROJECT": "Projetos Concedidos", "HUMANUSERS": "Usuários", - "MACHINEUSERS": "Usuários de Serviço", + "MACHINEUSERS": "Contas de serviço", "LOGOUT": "Encerrar Sessão de Todos os Usuários", "NEWORG": "Nova Organização", "IAMADMIN": "Você é um Administrador de instância. Observe que você possui permissões estendidas.", @@ -990,8 +990,8 @@ "COUNTRY": "País" }, "MACHINE": { - "TITLE": "Detalhes do Usuário de Serviço", - "USERNAME": "Nome de Usuário", + "TITLE": "Detalhes da Conta de Serviço", + "USERNAME": "Nome da Conta", "NAME": "Nome", "DESCRIPTION": "Descrição", "KEYSTITLE": "Chaves", diff --git a/console/src/assets/i18n/ro.json b/console/src/assets/i18n/ro.json index cbaa7ac5e..7b2d26410 100644 --- a/console/src/assets/i18n/ro.json +++ b/console/src/assets/i18n/ro.json @@ -53,9 +53,9 @@ "METADATA": "Adăugați atribute personalizate utilizatorului, cum ar fi departamentul. Puteți utiliza aceste informații în acțiunile dvs." }, "MACHINES": { - "TITLE": "Utilizatori de servicii", - "DESCRIPTION": "Utilizatorii de servicii se autentifică non-interactiv folosind un token JWT bearer semnat cu o cheie privată. De asemenea, pot utiliza un token de acces personal.", - "METADATA": "Adăugați atribute personalizate utilizatorului, cum ar fi sistemul de autentificare. Puteți utiliza aceste informații în acțiunile dvs." + "TITLE": "Conturi de serviciu", + "DESCRIPTION": "Conturile de serviciu se autentifică non-interactiv folosind un token JWT bearer semnat cu o cheie privată. De asemenea, pot utiliza un token de acces personal.", + "METADATA": "Adăugați atribute personalizate contului, cum ar fi sistemul de autentificare. Puteți utiliza aceste informații în acțiunile dvs." }, "SELF": { "METADATA": "Adăugați atribute personalizate utilizatorului dvs., cum ar fi departamentul. Puteți utiliza aceste informații în acțiunile organizațiilor dvs." @@ -424,7 +424,7 @@ "ROLES": "Roluri", "GRANTEDPROJECT": "Proiecte acordate", "HUMANUSERS": "Utilizatori", - "MACHINEUSERS": "Utilizatori de servicii", + "MACHINEUSERS": "Conturi de serviciu", "LOGOUT": "Deconectați toți utilizatorii", "NEWORG": "Organizație nouă", "IAMADMIN": "Sunteți administrator de instanță. Rețineți că aveți permisiuni extinse.", diff --git a/console/src/assets/i18n/ru.json b/console/src/assets/i18n/ru.json index c1d381907..28d58ed1f 100644 --- a/console/src/assets/i18n/ru.json +++ b/console/src/assets/i18n/ru.json @@ -53,9 +53,9 @@ "METADATA": "Добавьте пользовательские атрибуты к пользователю, такие как отдел. Вы можете использовать эту информацию в своих действиях." }, "MACHINES": { - "TITLE": "Пользователи сервиса", - "DESCRIPTION": "Пользователи службы проходят аутентификацию в неинтерактивном режиме с использованием токена носителя JWT, подписанного закрытым ключом. Они также могут использовать токен личного доступа.", - "METADATA": "Добавьте пользовательские атрибуты к пользователю, такие как система аутентификации. Вы можете использовать эту информацию в своих действиях." + "TITLE": "Служебные учетные записи", + "DESCRIPTION": "Служебные учетные записи проходят аутентификацию в неинтерактивном режиме с использованием токена носителя JWT, подписанного закрытым ключом. Они также могут использовать токен личного доступа.", + "METADATA": "Добавьте пользовательские атрибуты к учетной записи, такие как система аутентификации. Вы можете использовать эту информацию в своих действиях." }, "SELF": { "METADATA": "Добавьте пользовательские атрибуты к себе, такие как ваш отдел. Вы можете использовать эту информацию в действиях вашей организации." @@ -432,7 +432,7 @@ "ROLES": "Роли", "GRANTEDPROJECT": "Допуски проектов", "HUMANUSERS": "Пользователи", - "MACHINEUSERS": "Служебные пользователи", + "MACHINEUSERS": "Учетные записи услуги", "LOGOUT": "Выйти из всех пользователей", "NEWORG": "Новая организация", "IAMADMIN": "Вы являетесь администратором Инстанс. Обратите внимание, что вы обладаете расширенными разрешениями.", @@ -1005,7 +1005,7 @@ "COUNTRY": "Страна" }, "MACHINE": { - "TITLE": "Сведения о служебном пользователе", + "TITLE": "Сведения об учетной записи услуги", "USERNAME": "Имя пользователя", "NAME": "Имя", "DESCRIPTION": "Описание", diff --git a/console/src/assets/i18n/sv.json b/console/src/assets/i18n/sv.json index 6fc34ebfe..3f304d5e8 100644 --- a/console/src/assets/i18n/sv.json +++ b/console/src/assets/i18n/sv.json @@ -53,9 +53,9 @@ "METADATA": "Lägg till anpassade attribut till användaren som avdelningen. Du kan använda denna information i dina åtgärder." }, "MACHINES": { - "TITLE": "Tjänsteanvändare", - "DESCRIPTION": "Tjänsteanvändare autentiserar icke-interaktivt med en JWT-bärare token signerad med en privat nyckel. De kan också använda en personlig åtkomsttoken.", - "METADATA": "Lägg till anpassade attribut till användaren som autentiseringssystemet. Du kan använda denna information i dina åtgärder." + "TITLE": "Tjänstekonton", + "DESCRIPTION": "Tjänstekonton autentiserar icke-interaktivt med en JWT-bärare token signerad med en privat nyckel. De kan också använda en personlig åtkomsttoken.", + "METADATA": "Lägg till anpassade attribut till kontot som autentiseringssystemet. Du kan använda denna information i dina åtgärder." }, "SELF": { "METADATA": "Lägg till anpassade attribut till din användare som din avdelning. Du kan använda denna information i din organisations åtgärder." @@ -424,7 +424,7 @@ "ROLES": "Roller", "GRANTEDPROJECT": "Beviljade Projekt", "HUMANUSERS": "Användare", - "MACHINEUSERS": "Tjänsteanvändare", + "MACHINEUSERS": "Tjänstekonton", "LOGOUT": "Logga ut alla användare", "NEWORG": "Ny Organisation", "IAMADMIN": "Du är en instans-administratör. Observera att du har utökade behörigheter.", @@ -990,8 +990,8 @@ "COUNTRY": "Land" }, "MACHINE": { - "TITLE": "Användardetaljer för tjänst", - "USERNAME": "Användarnamn", + "TITLE": "Detaljer för tjänstekonto", + "USERNAME": "Kontonamn", "NAME": "Namn", "DESCRIPTION": "Beskrivning", "KEYSTITLE": "Nycklar", @@ -1152,7 +1152,7 @@ "SELECTEDDEACTIVATED": "Valda användare deaktiverade.", "SELECTEDKEYSDELETED": "Valda nycklar raderade.", "KEYADDED": "Nyckel tillagd!", - "MACHINEADDED": "Serviceanvändare skapad!", + "MACHINEADDED": "Tjänstekonto skapat!", "DELETED": "Användare raderad framgångsrikt!", "UNLOCKED": "Användare upplåst framgångsrikt!", "PASSWORDLESSREGISTRATIONSENT": "Registreringslänk skickad framgångsrikt.", diff --git a/console/src/assets/i18n/tr.json b/console/src/assets/i18n/tr.json index c20d3bff8..7ef4dd660 100644 --- a/console/src/assets/i18n/tr.json +++ b/console/src/assets/i18n/tr.json @@ -53,9 +53,9 @@ "METADATA": "Kullanıcıya departman gibi özel öznitelikler ekleyin. Bu bilgileri eylemlerinizde kullanabilirsiniz." }, "MACHINES": { - "TITLE": "Servis Kullanıcıları", - "DESCRIPTION": "Servis Kullanıcıları, özel anahtar ile imzalanmış JWT bearer token kullanarak etkileşimsiz kimlik doğrulaması yapar. Ayrıca kişisel erişim belirteci de kullanabilirler.", - "METADATA": "Kullanıcıya kimlik doğrulayan sistem gibi özel öznitelikler ekleyin. Bu bilgileri eylemlerinizde kullanabilirsiniz." + "TITLE": "Hizmet Hesapları", + "DESCRIPTION": "Hizmet Hesapları, özel anahtar ile imzalanmış JWT bearer token kullanarak etkileşimsiz kimlik doğrulaması yapar. Ayrıca kişisel erişim belirteci de kullanabilirler.", + "METADATA": "Hesaba kimlik doğrulayan sistem gibi özel öznitelikler ekleyin. Bu bilgileri eylemlerinizde kullanabilirsiniz." }, "SELF": { "METADATA": "Kullanıcınıza departmanınız gibi özel öznitelikler ekleyin. Bu bilgileri organizasyonunuzun eylemlerinde kullanabilirsiniz." @@ -424,7 +424,7 @@ "ROLES": "Roller", "GRANTEDPROJECT": "Verilen Projeler", "HUMANUSERS": "Kullanıcılar", - "MACHINEUSERS": "Servis Kullanıcıları", + "MACHINEUSERS": "Hizmet Hesapları", "LOGOUT": "Tüm Kullanıcıları Çıkış Yap", "NEWORG": "Yeni Organizasyon", "IAMADMIN": "instans Yöneticisisiniz. Genişletilmiş izinleriniz olduğunu unutmayın.", diff --git a/console/src/assets/i18n/uk.json b/console/src/assets/i18n/uk.json index 6886ae6b8..c63af3a7f 100644 --- a/console/src/assets/i18n/uk.json +++ b/console/src/assets/i18n/uk.json @@ -53,9 +53,9 @@ "METADATA": "Додайте власні атрибути до користувача, такі як відділ. Ви можете використовувати цю інформацію у своїх діях." }, "MACHINES": { - "TITLE": "Сервісні користувачі", - "DESCRIPTION": "Сервісні користувачі автентифікуються неінтерактивно, використовуючи JWT bearer токен, підписаний приватним ключем. Вони також можуть використовувати персональний токен доступу.", - "METADATA": "Додайте власні атрибути до користувача, такі як система автентифікації. Ви можете використовувати цю інформацію у своїх діях." + "TITLE": "Облікові записи служби", + "DESCRIPTION": "Облікові записи служби автентифікуються неінтерактивно, використовуючи JWT bearer токен, підписаний приватним ключем. Вони також можуть використовувати персональний токен доступу.", + "METADATA": "Додайте власні атрибути до облікового запису, такі як система автентифікації. Ви можете використовувати цю інформацію у своїх діях." }, "SELF": { "METADATA": "Додайте власні атрибути до свого користувача, такі як ваш відділ. Ви можете використовувати цю інформацію в діях вашої організації." @@ -424,7 +424,7 @@ "ROLES": "Ролі", "GRANTEDPROJECT": "Надані проекти", "HUMANUSERS": "Користувачі", - "MACHINEUSERS": "Сервісні користувачі", + "MACHINEUSERS": "Облікові записи служби", "LOGOUT": "Вийти з усіх користувачів", "NEWORG": "Нова організація", "IAMADMIN": "Ви адміністратор інстанс. Зверніть увагу, що у вас є розширені дозволи.", diff --git a/console/src/assets/i18n/zh.json b/console/src/assets/i18n/zh.json index 0bca61146..880037cfe 100644 --- a/console/src/assets/i18n/zh.json +++ b/console/src/assets/i18n/zh.json @@ -53,8 +53,8 @@ "METADATA": "为用户添加自定义属性，如部门。你可以在你的行动中使用这些信息。" }, "MACHINES": { - "TITLE": "服务用户", - "DESCRIPTION": "服务用户使用使用私钥签名的 JWT 不记名令牌进行非交互式身份验证。他们还可以使用个人访问令牌。", + "TITLE": "服务账户", + "DESCRIPTION": "服务账户使用使用私钥签名的 JWT 不记名令牌进行非交互式身份验证。他们还可以使用个人访问令牌。", "METADATA": "为用户添加自定义属性，如认证系统。你可以在你的行动中使用这些信息。" }, "SELF": { @@ -424,7 +424,7 @@ "ROLES": "角色", "GRANTEDPROJECT": "已授予的项目", "HUMANUSERS": "用户", - "MACHINEUSERS": "服务用户", + "MACHINEUSERS": "服务账户", "LOGOUT": "退出所有账户", "NEWORG": "创建组织", "IAMADMIN": "您是实例管理员。请注意您具有扩展权限。", @@ -990,7 +990,7 @@ "COUNTRY": "国家" }, "MACHINE": { - "TITLE": "服务用户详情", + "TITLE": "服务账户详情", "USERNAME": "用户名", "NAME": "名称", "DESCRIPTION": "描述", @@ -1152,7 +1152,7 @@ "SELECTEDDEACTIVATED": "选中的用户已被停用。", "SELECTEDKEYSDELETED": "选中的 Keys 已被删除。", "KEYADDED": "Key 已添加！", - "MACHINEADDED": "服务用户已创建成功!", + "MACHINEADDED": "服务账户已创建成功!", "DELETED": "用户删除成功!", "UNLOCKED": "用户解锁成功!", "PASSWORDLESSREGISTRATIONSENT": "注册链接发送成功。", diff --git a/internal/api/authz/context.go b/internal/api/authz/context.go index ff2fa8d44..d068b6987 100644 --- a/internal/api/authz/context.go +++ b/internal/api/authz/context.go @@ -151,7 +151,7 @@ func projectIDAndCheckOriginForClientID(ctx context.Context, clientID string, t projectID, origins, err := t.ProjectIDAndOriginsByClientID(ctx, clientID) logging.WithFields("clientID", clientID).OnError(err).Debug("could not check projectID and origin of clientID (might be service account)") - // We used to check origins for every token, but service users shouldn't be used publicly (native app / SPA). + // We used to check origins for every token, but service accounts shouldn't be used publicly (native app / SPA). // Therefore, mostly won't send an origin and aren't able to configure them anyway. // For the current time we will only check origins for tokens issued to users through apps (code / implicit flow). if projectID == "" { diff --git a/internal/api/grpc/internal_permission/v2/integration_test/query_test.go b/internal/api/grpc/internal_permission/v2/integration_test/query_test.go index cc033f203..3d34c16c9 100644 --- a/internal/api/grpc/internal_permission/v2/integration_test/query_test.go +++ b/internal/api/grpc/internal_permission/v2/integration_test/query_test.go @@ -29,7 +29,7 @@ func TestServer_ListAdministrators(t *testing.T) { organizationAdmin2 := createOrganizationAdministrator(iamOwnerCtx, instanceQuery, organizationResp.GetOrganizationId(), organizationName, t) organizationAdmin3 := createOrganizationAdministrator(iamOwnerCtx, instanceQuery, organizationResp.GetOrganizationId(), organizationName, t) - // Additionally, a machine user as a project grant owner to test permissions + // Additionally, a service account as a project grant owner to test permissions userOrganizationResp := instanceQuery.CreateMachineUser(iamOwnerCtx) instanceQuery.CreateOrgMembership(t, iamOwnerCtx, organizationResp.GetOrganizationId(), userOrganizationResp.GetUserId()) patOrganizationResp := instanceQuery.CreatePersonalAccessToken(iamOwnerCtx, userOrganizationResp.GetUserId()) @@ -42,7 +42,7 @@ func TestServer_ListAdministrators(t *testing.T) { projectAdministrator2 := createProjectAdministrator(iamOwnerCtx, instanceQuery, t, organizationResp.GetOrganizationId(), projectResp.GetId(), projectName) projectAdministrator3 := createProjectAdministrator(iamOwnerCtx, instanceQuery, t, organizationResp.GetOrganizationId(), projectResp.GetId(), projectName) - // Additionally, a machine user as a project owner to test permissions + // Additionally, a service account as a project owner to test permissions userProjectResp := instanceQuery.CreateMachineUser(iamOwnerCtx) instanceQuery.CreateProjectMembership(t, iamOwnerCtx, projectResp.GetId(), userProjectResp.GetUserId()) patProjectResp := instanceQuery.CreatePersonalAccessToken(iamOwnerCtx, userProjectResp.GetUserId()) @@ -56,7 +56,7 @@ func TestServer_ListAdministrators(t *testing.T) { projectGrantAdministrator2 := createProjectGrantAdministrator(iamOwnerCtx, instanceQuery, t, organizationResp.GetOrganizationId(), projectResp.GetId(), projectName, grantedOrganizationResp.GetOrganizationId()) projectGrantAdministrator3 := createProjectGrantAdministrator(iamOwnerCtx, instanceQuery, t, organizationResp.GetOrganizationId(), projectResp.GetId(), projectName, grantedOrganizationResp.GetOrganizationId()) - // Additionally, a machine user as a project grant owner to test permissions + // Additionally, a service account as a project grant owner to test permissions userProjectGrantResp := instanceQuery.CreateMachineUser(iamOwnerCtx) instanceQuery.CreateProjectGrantMembership(t, iamOwnerCtx, projectResp.GetId(), grantedOrganizationResp.GetOrganizationId(), userProjectGrantResp.GetUserId()) patProjectGrantResp := instanceQuery.CreatePersonalAccessToken(iamOwnerCtx, userProjectGrantResp.GetUserId()) @@ -845,7 +845,7 @@ func TestServer_ListAdministrators_PermissionV2(t *testing.T) { organizationAdmin2 := createOrganizationAdministrator(iamOwnerCtx, instancePermissionV2, organizationResp.GetOrganizationId(), organizationName, t) organizationAdmin3 := createOrganizationAdministrator(iamOwnerCtx, instancePermissionV2, organizationResp.GetOrganizationId(), organizationName, t) - // Additionally, a machine user as a project grant owner to test permissions + // Additionally, a service account as a project grant owner to test permissions userOrganizationResp := instancePermissionV2.CreateMachineUser(iamOwnerCtx) instancePermissionV2.CreateOrgMembership(t, iamOwnerCtx, organizationResp.GetOrganizationId(), userOrganizationResp.GetUserId()) patOrganizationResp := instancePermissionV2.CreatePersonalAccessToken(iamOwnerCtx, userOrganizationResp.GetUserId()) @@ -858,7 +858,7 @@ func TestServer_ListAdministrators_PermissionV2(t *testing.T) { projectAdministrator2 := createProjectAdministrator(iamOwnerCtx, instancePermissionV2, t, organizationResp.GetOrganizationId(), projectResp.GetId(), projectName) projectAdministrator3 := createProjectAdministrator(iamOwnerCtx, instancePermissionV2, t, organizationResp.GetOrganizationId(), projectResp.GetId(), projectName) - // Additionally, a machine user as a project owner to test permissions + // Additionally, a service account as a project owner to test permissions userProjectResp := instancePermissionV2.CreateMachineUser(iamOwnerCtx) instancePermissionV2.CreateProjectMembership(t, iamOwnerCtx, projectResp.GetId(), userProjectResp.GetUserId()) patProjectResp := instancePermissionV2.CreatePersonalAccessToken(iamOwnerCtx, userProjectResp.GetUserId()) @@ -872,7 +872,7 @@ func TestServer_ListAdministrators_PermissionV2(t *testing.T) { projectGrantAdministrator2 := createProjectGrantAdministrator(iamOwnerCtx, instancePermissionV2, t, organizationResp.GetOrganizationId(), projectResp.GetId(), projectName, grantedOrganizationResp.GetOrganizationId()) projectGrantAdministrator3 := createProjectGrantAdministrator(iamOwnerCtx, instancePermissionV2, t, organizationResp.GetOrganizationId(), projectResp.GetId(), projectName, grantedOrganizationResp.GetOrganizationId()) - // Additionally, a machine user as a project grant owner to test permissions + // Additionally, a service account as a project grant owner to test permissions userProjectGrantResp := instancePermissionV2.CreateMachineUser(iamOwnerCtx) instancePermissionV2.CreateProjectGrantMembership(t, iamOwnerCtx, projectResp.GetId(), grantedOrganizationResp.GetOrganizationId(), userProjectGrantResp.GetUserId()) patProjectGrantResp := instancePermissionV2.CreatePersonalAccessToken(iamOwnerCtx, userProjectGrantResp.GetUserId()) diff --git a/internal/api/grpc/project/v2/integration_test/project_test.go b/internal/api/grpc/project/v2/integration_test/project_test.go index b43effa01..d5eb57d40 100644 --- a/internal/api/grpc/project/v2/integration_test/project_test.go +++ b/internal/api/grpc/project/v2/integration_test/project_test.go @@ -221,7 +221,7 @@ func TestServer_CreateProject_Permission(t *testing.T) { } func getOrgProjectCreatorToken(t *testing.T, ctx context.Context, orgId1, orgId2 string) string { - // create a machine user in Org 1 + // create a service account in Org 1 userResp := instance.CreateUserTypeMachine(ctx, orgId1) // assign ORG_PROJECT_CREATOR role in Org 2 @@ -970,7 +970,6 @@ func TestServer_ActivateProject(t *testing.T) { name: "not existing", prepare: func(request *project.ActivateProjectRequest) { request.ProjectId = "notexisting" - return }, args: args{ ctx: iamOwnerCtx, diff --git a/internal/api/grpc/project/v2beta/integration_test/project_test.go b/internal/api/grpc/project/v2beta/integration_test/project_test.go index 0b591f5bd..3b2819d65 100644 --- a/internal/api/grpc/project/v2beta/integration_test/project_test.go +++ b/internal/api/grpc/project/v2beta/integration_test/project_test.go @@ -200,7 +200,7 @@ func TestServer_CreateProject_Permission(t *testing.T) { } func getOrgProjectCreatorToken(t *testing.T, ctx context.Context, orgId1, orgId2 string) string { - // create a machine user in Org 1 + // create a service account in Org 1 userResp := instance.CreateUserTypeMachine(ctx, orgId1) // assign ORG_PROJECT_CREATOR role in Org 2 @@ -953,7 +953,6 @@ func TestServer_ActivateProject(t *testing.T) { name: "not existing", prepare: func(request *project.ActivateProjectRequest) { request.Id = "notexisting" - return }, args: args{ ctx: iamOwnerCtx, diff --git a/internal/api/grpc/user/v2/convert/user_test.go b/internal/api/grpc/user/v2/convert/user_test.go index f6d59a9b2..471d8701e 100644 --- a/internal/api/grpc/user/v2/convert/user_test.go +++ b/internal/api/grpc/user/v2/convert/user_test.go @@ -824,7 +824,7 @@ func Test_UsersToPb(t *testing.T) { }, }, { - name: "slice with one machine user", + name: "slice with one service account", args: args{ users: []*query.User{ { diff --git a/internal/api/grpc/user/v2/integration_test/query_test.go b/internal/api/grpc/user/v2/integration_test/query_test.go index c7edcb795..f96adb556 100644 --- a/internal/api/grpc/user/v2/integration_test/query_test.go +++ b/internal/api/grpc/user/v2/integration_test/query_test.go @@ -398,7 +398,7 @@ func TestServer_ListUsers(t *testing.T) { wantErr bool }{ { - name: "list user by id, no permission machine user", + name: "list user by id, no permission service account", args: args{ InstancePermissionV2.WithAuthorizationToken(OrgCTX, integration.UserTypeNoPermission), &user.ListUsersRequest{}, diff --git a/internal/api/grpc/user/v2/integration_test/user_test.go b/internal/api/grpc/user/v2/integration_test/user_test.go index 069b2e862..12b18daf0 100644 --- a/internal/api/grpc/user/v2/integration_test/user_test.go +++ b/internal/api/grpc/user/v2/integration_test/user_test.go @@ -3358,7 +3358,7 @@ func TestServer_CreateUser(t *testing.T) { }, }, { - name: "machine user", + name: "service account", testCase: func(runId string) testCase { username := fmt.Sprintf("donald.duck+%s", runId) return testCase{ @@ -3577,7 +3577,7 @@ func TestServer_CreateUser_And_Compare(t *testing.T) { } }, }, { - name: "machine username given", + name: "service accountname given", testCase: func(runId string) testCase { username := fmt.Sprintf("donald.duck+%s", runId) return testCase{ @@ -3599,7 +3599,7 @@ func TestServer_CreateUser_And_Compare(t *testing.T) { } }, }, { - name: "machine username default to generated id", + name: "service accountname default to generated id", testCase: func(runId string) testCase { return testCase{ args: args{ @@ -3619,7 +3619,7 @@ func TestServer_CreateUser_And_Compare(t *testing.T) { } }, }, { - name: "machine username default to given id", + name: "service accountname default to given id", testCase: func(runId string) testCase { return testCase{ args: args{ @@ -3795,7 +3795,7 @@ func TestServer_CreateUser_Permission(t *testing.T) { wantErr: true, }, { - name: "machine user, error", + name: "service account, error", args: args{ UserCTX, &user.CreateUserRequest{ @@ -4150,7 +4150,7 @@ func TestServer_UpdateUserTypeMachine(t *testing.T) { }, }, { - name: "update machine user with human fields, error", + name: "update service account with human fields, error", testCase: func(runId, userId string) testCase { return testCase{ args: args{ @@ -4280,7 +4280,7 @@ func TestServer_UpdateUser_And_Compare(t *testing.T) { } }, }, { - name: "machine username", + name: "service accountname", testCase: func(runId string) testCase { username := fmt.Sprintf("donald.duck+%s", runId) return testCase{ @@ -4493,7 +4493,7 @@ func TestServer_UpdateUser_Permission(t *testing.T) { }, }, { - name: "machine user, error", + name: "service account, error", testCase: func() testCase { return testCase{ args: args{ diff --git a/internal/api/grpc/user/v2beta/integration_test/query_test.go b/internal/api/grpc/user/v2beta/integration_test/query_test.go index f8a588818..3e9388169 100644 --- a/internal/api/grpc/user/v2beta/integration_test/query_test.go +++ b/internal/api/grpc/user/v2beta/integration_test/query_test.go @@ -393,7 +393,7 @@ func TestServer_ListUsers(t *testing.T) { wantErr bool }{ { - name: "list user by id, no permission machine user", + name: "list user by id, no permission service account", args: args{ UserCTX, &user_v2beta.ListUsersRequest{}, diff --git a/internal/api/oidc/client_credentials.go b/internal/api/oidc/client_credentials.go index a76a535ca..c21c7fa5b 100644 --- a/internal/api/oidc/client_credentials.go +++ b/internal/api/oidc/client_credentials.go @@ -51,12 +51,12 @@ type clientCredentialsClient struct { } // AccessTokenType returns the AccessTokenType for the token to be created because of the client credentials request -// machine users currently only have opaque tokens ([op.AccessTokenTypeBearer]) +// service accounts currently only have opaque tokens ([op.AccessTokenTypeBearer]) func (c *clientCredentialsClient) AccessTokenType() op.AccessTokenType { return accessTokenTypeToOIDC(c.tokenType) } -// GetID returns the client_id (username of the machine user) for the token to be created because of the client credentials request +// GetID returns the client_id (username of the service account) for the token to be created because of the client credentials request func (c *clientCredentialsClient) GetID() string { return c.clientID } @@ -71,12 +71,12 @@ func (c *clientCredentialsClient) PostLogoutRedirectURIs() []string { return nil } -// ApplicationType returns [op.ApplicationTypeWeb] as the machine users is a confidential client +// ApplicationType returns [op.ApplicationTypeWeb] as the service accounts is a confidential client func (c *clientCredentialsClient) ApplicationType() op.ApplicationType { return op.ApplicationTypeWeb } -// AuthMethod returns the allowed auth method type for machine user. +// AuthMethod returns the allowed auth method type for service account. // It returns Basic Auth func (c *clientCredentialsClient) AuthMethod() oidc.AuthMethod { return oidc.AuthMethodBasic @@ -87,7 +87,7 @@ func (c *clientCredentialsClient) ResponseTypes() []oidc.ResponseType { return nil } -// GrantTypes returns the grant types supported by the machine users, which is currently only client credentials ([oidc.GrantTypeClientCredentials]) +// GrantTypes returns the grant types supported by the service accounts, which is currently only client credentials ([oidc.GrantTypeClientCredentials]) func (c *clientCredentialsClient) GrantTypes() []oidc.GrantType { return []oidc.GrantType{ oidc.GrantTypeClientCredentials, @@ -132,7 +132,7 @@ func (c *clientCredentialsClient) IDTokenUserinfoClaimsAssertion() bool { // ClockSkew enable handling clock skew of the token validation. The duration (0-5s) will be added to exp claim and subtracted from iats, // auth_time and nbf of the token to be created because of the client credentials request. -// It returns 0 as clock skew is not implemented on machine users. +// It returns 0 as clock skew is not implemented on service accounts. func (c *clientCredentialsClient) ClockSkew() time.Duration { return 0 } diff --git a/internal/api/oidc/integration_test/token_client_credentials_test.go b/internal/api/oidc/integration_test/token_client_credentials_test.go index 4efe1d327..4c94597bc 100644 --- a/internal/api/oidc/integration_test/token_client_credentials_test.go +++ b/internal/api/oidc/integration_test/token_client_credentials_test.go @@ -59,7 +59,7 @@ func TestServer_ClientCredentialsExchange(t *testing.T) { wantErr: true, }, { - name: "machine user without secret error", + name: "service account without secret error", clientID: func() string { name := integration.Username() _, err := Instance.Client.Mgmt.AddMachineUser(CTX, &management.AddMachineUserRequest{ @@ -75,7 +75,7 @@ func TestServer_ClientCredentialsExchange(t *testing.T) { wantErr: true, }, { - name: "inactive machine user error", + name: "inactive service account error", clientID: clientIDInactive, clientSecret: clientSecretInactive, scope: []string{oidc.ScopeOpenID}, diff --git a/internal/api/oidc/token_client_credentials.go b/internal/api/oidc/token_client_credentials.go index ea2d933cc..648fac6fa 100644 --- a/internal/api/oidc/token_client_credentials.go +++ b/internal/api/oidc/token_client_credentials.go @@ -35,7 +35,7 @@ func (s *Server) ClientCredentialsExchange(ctx context.Context, r *op.ClientRequ client.userID, client.resourceOwner, client.clientID, - "", // backChannelLogoutURI not needed for service user session + "", // backChannelLogoutURI not needed for service account session scope, domain.AddAudScopeToAudience(ctx, nil, r.Data.Scope), []domain.UserAuthMethodType{domain.UserAuthMethodTypePassword}, diff --git a/internal/api/oidc/token_jwt_profile.go b/internal/api/oidc/token_jwt_profile.go index 5283d7599..cbcd069c2 100644 --- a/internal/api/oidc/token_jwt_profile.go +++ b/internal/api/oidc/token_jwt_profile.go @@ -45,7 +45,7 @@ func (s *Server) JWTProfile(ctx context.Context, r *op.Request[oidc.JWTProfileGr client.userID, client.resourceOwner, client.clientID, - "", // backChannelLogoutURI not needed for service user session + "", // backChannelLogoutURI not needed for service account session scope, domain.AddAudScopeToAudience(ctx, nil, r.Data.Scope), []domain.UserAuthMethodType{domain.UserAuthMethodTypePrivateKey}, diff --git a/internal/api/scim/integration_test/users_create_test.go b/internal/api/scim/integration_test/users_create_test.go index 6e0036187..1ccd56a80 100644 --- a/internal/api/scim/integration_test/users_create_test.go +++ b/internal/api/scim/integration_test/users_create_test.go @@ -412,12 +412,11 @@ func TestCreateUser_scopedExternalID(t *testing.T) { retryDuration, tick := integration.WaitForAndTickWithMaxDuration(ctx, time.Minute) require.EventuallyWithT(t, func(tt *assert.CollectT) { // unscoped externalID should not exist - unscoped, err := Instance.Client.Mgmt.GetUserMetadata(ctx, &management.GetUserMetadataRequest{ + _, err := Instance.Client.Mgmt.GetUserMetadata(ctx, &management.GetUserMetadataRequest{ Id: createdUser.ID, Key: "urn:zitadel:scim:externalId", }) integration.AssertGrpcStatus(tt, codes.NotFound, err) - unscoped = unscoped // scoped externalID should exist md, err := Instance.Client.Mgmt.GetUserMetadata(ctx, &management.GetUserMetadataRequest{ @@ -478,12 +477,12 @@ func TestCreateUser_ignorePasswordOnCreate(t *testing.T) { for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { t.Parallel() - // create a machine user + // create a service account callingUserId, callingUserPat, err := Instance.CreateMachineUserPATWithMembership(CTX, "ORG_OWNER") require.NoError(t, err) ctx := integration.WithAuthorizationToken(CTX, callingUserPat) - // set urn:zitadel:scim:ignorePasswordOnCreate metadata for the machine user + // set urn:zitadel:scim:ignorePasswordOnCreate metadata for the service account setAndEnsureMetadata(t, callingUserId, "urn:zitadel:scim:ignorePasswordOnCreate", tt.ignorePassword) // create a user with an invalid password diff --git a/internal/api/scim/integration_test/users_list_test.go b/internal/api/scim/integration_test/users_list_test.go index 7d422574a..9454b005a 100644 --- a/internal/api/scim/integration_test/users_list_test.go +++ b/internal/api/scim/integration_test/users_list_test.go @@ -365,7 +365,7 @@ var totalCountOfHumanUsers = 13 prepare: func(t require.TestingT) *scim.ListRequest { resp := createHumanUser(t, CTX, Instance.DefaultOrg.Id, 102) - // set provisioning domain of service user + // set provisioning domain of service account setProvisioningDomain(t, Instance.Users.Get(integration.UserTypeOrgOwner).ID, "fooBar") // set externalID for provisioning domain @@ -379,7 +379,7 @@ var totalCountOfHumanUsers = 13 assert.Equal(t, resp.Resources[0].ExternalID, "100-scopedExternalId") }, cleanup: func(t require.TestingT) { - // delete provisioning domain of service user + // delete provisioning domain of service account removeProvisioningDomain(t, Instance.Users.Get(integration.UserTypeOrgOwner).ID) }, }, diff --git a/internal/api/scim/integration_test/users_replace_test.go b/internal/api/scim/integration_test/users_replace_test.go index c3cdf90eb..0eaa7d367 100644 --- a/internal/api/scim/integration_test/users_replace_test.go +++ b/internal/api/scim/integration_test/users_replace_test.go @@ -344,7 +344,7 @@ func TestReplaceUser_scopedExternalID(t *testing.T) { callingUserId, callingUserPat, err := Instance.CreateMachineUserPATWithMembership(CTX, "ORG_OWNER") require.NoError(t, err) ctx := integration.WithAuthorizationToken(CTX, callingUserPat) - // set provisioning domain of service user + // set provisioning domain of service account setProvisioningDomain(t, callingUserId, "fooBazz") // replace the user with provisioning domain set diff --git a/internal/api/scim/middleware/scim_context_middleware.go b/internal/api/scim/middleware/scim_context_middleware.go index e9b6f48aa..5774e1575 100644 --- a/internal/api/scim/middleware/scim_context_middleware.go +++ b/internal/api/scim/middleware/scim_context_middleware.go @@ -35,7 +35,7 @@ func initScimContext(ctx context.Context, q *query.Queries) (context.Context, er userID := authz.GetCtxData(ctx).UserID - // get the provisioningDomain and ignorePasswordOnCreate metadata keys associated with the service user + // get the provisioningDomain and ignorePasswordOnCreate metadata keys associated with the service account metadataKeys := []smetadata.Key{ smetadata.KeyProvisioningDomain, smetadata.KeyIgnorePasswordOnCreate, diff --git a/internal/auth/repository/eventsourcing/eventstore/auth_request.go b/internal/auth/repository/eventsourcing/eventstore/auth_request.go index 38036c8fa..6de05e472 100644 --- a/internal/auth/repository/eventsourcing/eventstore/auth_request.go +++ b/internal/auth/repository/eventsourcing/eventstore/auth_request.go @@ -855,7 +855,7 @@ func (repo *AuthRequestRepo) checkLoginName(ctx context.Context, request *domain if err != nil { return err } - // let's check if it was a machine user + // let's check if it was a service account if !user.MachineView.IsZero() { return zerrors.ThrowPreconditionFailed(nil, "AUTH-DGV4g", "Errors.User.NotHuman") } diff --git a/internal/authz/repository/eventsourcing/eventstore/token_verifier.go b/internal/authz/repository/eventsourcing/eventstore/token_verifier.go index f6bb97dc4..919bd61eb 100644 --- a/internal/authz/repository/eventsourcing/eventstore/token_verifier.go +++ b/internal/authz/repository/eventsourcing/eventstore/token_verifier.go @@ -186,7 +186,7 @@ func (repo *TokenVerifierRepo) checkAuthentication(ctx context.Context, authMeth if err != nil { return err } - // machine users do not have interactive logins, so we don't check for MFA requirements + // service accounts do not have interactive logins, so we don't check for MFA requirements if requirements.UserType == domain.UserTypeMachine { return nil } diff --git a/internal/command/instance_test.go b/internal/command/instance_test.go index 75a4f8b28..c5796f948 100644 --- a/internal/command/instance_test.go +++ b/internal/command/instance_test.go @@ -658,7 +658,7 @@ func addHumanEvent(ctx context.Context, orgID, userID string) *user.HumanAddedEv }() } -// machineEvents all events from setup to create the machine user, machinekey can't be tested here, as the public key is not provided and as such the value in the event can't be expected +// machineEvents all events from setup to create the service account, machinekey can't be tested here, as the public key is not provided and as such the value in the event can't be expected func machineEvents(ctx context.Context, instanceID, orgID, userID, patID string) []eventstore.Command { agg := user.NewAggregate(userID, orgID) instanceAgg := instance.NewAggregate(instanceID) diff --git a/internal/integration/client.go b/internal/integration/client.go index 0746eca96..fed90786a 100644 --- a/internal/integration/client.go +++ b/internal/integration/client.go @@ -329,7 +329,7 @@ func (i *Instance) CreateUserTypeMachine(ctx context.Context, orgId string) *use }, }, }) - logging.OnError(err).Panic("create machine user") + logging.OnError(err).Panic("create service account") i.TriggerUserByID(ctx, resp.GetId()) return resp } diff --git a/internal/integration/instance.go b/internal/integration/instance.go index 3cf2f5324..6f827c003 100644 --- a/internal/integration/instance.go +++ b/internal/integration/instance.go @@ -2,15 +2,12 @@ package integration import ( - "bytes" "context" "crypto/rsa" "crypto/x509" _ "embed" "errors" "fmt" - "os" - "path/filepath" "time" "github.com/zitadel/logging" @@ -39,7 +36,7 @@ const ( // UserType provides constants that give // a short explanation with the purpose -// a service user. +// a service account. // This allows to pre-create users with // different permissions and reuse them. type UserType int @@ -195,14 +192,6 @@ func (i *Instance) Host() string { return fmt.Sprintf("%s:%d", i.Domain, i.Config.Port) } -func loadInstanceOwnerPAT() string { - data, err := os.ReadFile(filepath.Join(tmpDir, adminPATFile)) - if err != nil { - panic(err) - } - return string(bytes.TrimSpace(data)) -} - func (i *Instance) createMachineUserInstanceOwner(ctx context.Context, token string) { mustAwait(func() error { user, err := i.Client.Auth.GetMyUser(WithAuthorizationToken(ctx, token), &auth.GetMyUserRequest{}) diff --git a/internal/query/testdata/userinfo_machine.json b/internal/query/testdata/userinfo_machine.json index daa865316..ffa92903a 100644 --- a/internal/query/testdata/userinfo_machine.json +++ b/internal/query/testdata/userinfo_machine.json @@ -11,7 +11,7 @@ "human": null, "machine": { "name": "tests", - "description": "My test service user" + "description": "My test service account" } }, "org": { diff --git a/internal/query/user_grant_test.go b/internal/query/user_grant_test.go index 0dc346529..ddd39d1c4 100644 --- a/internal/query/user_grant_test.go +++ b/internal/query/user_grant_test.go @@ -236,7 +236,7 @@ func Test_UserGrantPrepares(t *testing.T) { }, }, { - name: "prepareUserGrantQuery machine user found", + name: "prepareUserGrantQuery service account found", prepare: prepareUserGrantQuery, want: want{ sqlExpectations: mockQuery( @@ -634,7 +634,7 @@ func Test_UserGrantPrepares(t *testing.T) { }, }, { - name: "prepareUserGrantsQuery one grant (machine user)", + name: "prepareUserGrantsQuery one grant (service account)", prepare: prepareUserGrantsQuery, want: want{ sqlExpectations: mockQueries( diff --git a/internal/query/userinfo_test.go b/internal/query/userinfo_test.go index 531428363..ae8677349 100644 --- a/internal/query/userinfo_test.go +++ b/internal/query/userinfo_test.go @@ -395,7 +395,7 @@ func TestQueries_GetOIDCUserInfo(t *testing.T) { Human: nil, Machine: &Machine{ Name: "tests", - Description: "My test service user", + Description: "My test service account", }, }, Org: &UserInfoOrg{ diff --git a/proto/zitadel/management.proto b/proto/zitadel/management.proto index 5715926fe..8faa651e5 100644 --- a/proto/zitadel/management.proto +++ b/proto/zitadel/management.proto @@ -115,7 +115,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = { }, { name: "Users", - description: "ZITADEL knows two different types of users: Users (Human) and Service Users (Machine Accounts)" + description: "ZITADEL knows two different types of users: Users (Human) and Service Accounts" }, { name: "User Grants", @@ -1729,11 +1729,11 @@ service ManagementService { }; } - // Update Machine User + // Update Service Account // // Deprecated: use [user service v2 UpdateUser](apis/resources/user_service_v2/user-service-update-user.api.mdx) instead. // - // Change a service account/machine user. It is used for accounts with non-interactive authentication possibilities. + // Change a service account/service account. It is used for accounts with non-interactive authentication possibilities. rpc UpdateMachine(UpdateMachineRequest) returns (UpdateMachineResponse) { option (google.api.http) = { put: "/users/{user_id}/machine" @@ -1765,11 +1765,11 @@ service ManagementService { }; } - // Create Secret for Machine User + // Create Secret for Service Account // // Deprecated: use [user service v2 AddSecret](apis/resources/user_service_v2/user-service-add-secret.api.mdx) instead. // - // Create a new secret for a machine user/service account. It is used to authenticate the user (client credential grant). + // Create a new secret for a service account. It is used to authenticate the user (client credential grant). rpc GenerateMachineSecret(GenerateMachineSecretRequest) returns (GenerateMachineSecretResponse) { option (google.api.http) = { put: "/users/{user_id}/secret" @@ -1801,11 +1801,11 @@ service ManagementService { }; } - // Delete Secret of Machine User + // Delete Secret of Service Account // // Deprecated: use [user service v2 RemoveSecret](apis/resources/user_service_v2/user-service-remove-secret.api.mdx) instead. // - // Delete a secret of a machine user/service account. The user will not be able to authenticate with the secret afterward. + // Delete a secret of a service account. The user will not be able to authenticate with the secret afterward. rpc RemoveMachineSecret(RemoveMachineSecretRequest) returns (RemoveMachineSecretResponse) { option (google.api.http) = { delete: "/users/{user_id}/secret" @@ -1836,11 +1836,11 @@ service ManagementService { }; } - // Get Machine user Key By ID + // Get Service account Key By ID // // Deprecated: use [user service v2 ListUsers](apis/resources/user_service_v2/user-service-list-users.api.mdx) instead. // - // Get a specific Key of a machine user by its id. Machine keys are used to authenticate with jwt profile authentication. + // Get a specific Key of a service account by its id. Machine keys are used to authenticate with jwt profile authentication. rpc GetMachineKeyByIDs(GetMachineKeyByIDsRequest) returns (GetMachineKeyByIDsResponse) { option (google.api.http) = { get: "/users/{user_id}/keys/{key_id}" @@ -1875,7 +1875,7 @@ service ManagementService { // // Deprecated: use [user service v2 ListKeys](apis/resources/user_service_v2/user-service-list-keys.api.mdx) instead. // - // Get the list of keys of a machine user. Machine keys are used to authenticate with jwt profile authentication. + // Get the list of keys of a service account. Machine keys are used to authenticate with jwt profile authentication. rpc ListMachineKeys(ListMachineKeysRequest) returns (ListMachineKeysResponse) { option (google.api.http) = { post: "/users/{user_id}/keys/_search" @@ -1907,7 +1907,7 @@ service ManagementService { }; } - // Create Key for machine user + // Create Key for service account // // Deprecated: use [user service v2 AddKey](apis/resources/user_service_v2/user-service-add-key.api.mdx) instead. // @@ -1946,7 +1946,7 @@ service ManagementService { }; } - // Delete Key for machine user + // Delete Key for service account // // Deprecated: use [user service v2 RemoveKey](apis/resources/user_service_v2/user-service-remove-key.api.mdx) instead. // @@ -8834,14 +8834,14 @@ message AddMachineUserRequest { (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = { min_length: 1; max_length: 200; - example: "\"My Machine Account\""; + example: "\"My Service Account\""; } ]; string description = 3 [ (validate.rules).string = {max_len: 500}, (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = { max_length: 500; - example: "\"First machine account used for API XY.\""; + example: "\"First service account used for API XY.\""; } ]; diff --git a/proto/zitadel/user/v2/user_service.proto b/proto/zitadel/user/v2/user_service.proto index 7a779f828..f8c33646d 100644 --- a/proto/zitadel/user/v2/user_service.proto +++ b/proto/zitadel/user/v2/user_service.proto @@ -1504,7 +1504,7 @@ service UserService { // Remove a Users Secret // - // Remove the current client ID and client secret from a machine user. + // Remove the current client ID and client secret from a service account. // // Required permission: // - user.write @@ -1620,7 +1620,7 @@ service UserService { responses: { key: "200"; value: { - description: "A list of all machine user keys matching the query"; + description: "A list of all service account keys matching the query"; }; }; responses: {