Merge branch 'main' into move-go

This commit is contained in:
Florian Forster
2025-08-06 11:57:12 -07:00
81 changed files with 11866 additions and 2123 deletions

View File

@@ -184,7 +184,7 @@ https://github.com/zitadel/actions/blob/main/examples/add_metadata.js
## Use provided fields of identity providers
If you want to ensure that the data of a user are always update you can automatically update user fields during authentication and safe time of your customers and your team. 🤯
If you want to ensure that the data of a user are always up-to-date, you can automatically update user fields during authentication and save time of your customers and your team.
### Trigger
@@ -344,4 +344,4 @@ Allows you to limit the user interaction. The error thrown will be shown to the
```js reference
https://github.com/zitadel/actions/blob/main/examples/throw_error.js
```
</details>
</details>

View File

@@ -145,7 +145,7 @@ This object contains context information about the request to the [authorization
- `requestedOrgDomain` *bool*
- `applicationResourceOwner` *string*
- `privateLabelingSetting` *Number*
<ul><li>0: Unspecified</li><li>1: Enforce project resource owner policy</li><li>2: Allow login user resource owner policy</li></ul>
<ul><li>0: Unspecified</li><li>1: Enforce project's policy</li><li>2: Allow user's organization login policy</li></ul>
- `selectedIdpConfigId` *string*
- `linkingUsers` Array of [*ExternalUser*](#external-user)
- `passwordVerified` *bool*

View File

@@ -111,6 +111,6 @@ ZITADEL reserves some claims to assert certain data. Please check out the [reser
| urn:zitadel:iam:org:project:roles | `{"urn:zitadel:iam:org:project:roles": [ {"user": {"id1": "acme.zitade.ch", "id2": "caos.ch"} } ] }` | When roles are asserted, ZITADEL does this by providing the `id` and `primaryDomain` below the role. This gives you the option to check in which organization a user has the role on the current project (where your client belongs to). |
| urn:zitadel:iam:org:project:\{projectid}:roles | `{"urn:zitadel:iam:org:project:id3:roles": [ {"user": {"id1": "acme.zitade.ch", "id2": "caos.ch"} } ] }` | When roles are asserted, ZITADEL does this by providing the `id` and `primaryDomain` below the role. This gives you the option to check in which organization a user has the role on a specific project. |
| urn:zitadel:iam:user:metadata | `{"urn:zitadel:iam:user:metadata": [ {"key": "VmFsdWU=" } ] }` | The metadata claim will include all metadata of a user. The values are base64 encoded. |
| urn:zitadel:iam:user:resourceowner:id | `{"urn:zitadel:iam:user:resourceowner:id": "orgid"}` | This claim represents the id of the resource owner organisation of the user. |
| urn:zitadel:iam:user:resourceowner:name | `{"urn:zitadel:iam:user:resourceowner:name": "ACME"}` | This claim represents the name of the resource owner organisation of the user. |
| urn:zitadel:iam:user:resourceowner:primary_domain | `{"urn:zitadel:iam:user:resourceowner:primary_domain": "acme.ch"}` | This claim represents the primary domain of the resource owner organisation of the user. |
| urn:zitadel:iam:user:resourceowner:id | `{"urn:zitadel:iam:user:resourceowner:id": "orgid"}` | This claim represents the user's organization ID. |
| urn:zitadel:iam:user:resourceowner:name | `{"urn:zitadel:iam:user:resourceowner:name": "ACME"}` | This claim represents the user's organization's name. |
| urn:zitadel:iam:user:resourceowner:primary_domain | `{"urn:zitadel:iam:user:resourceowner:primary_domain": "acme.ch"}` | This claim represents the user's organization's primary domain. |

View File

@@ -31,8 +31,8 @@ In addition to the standard compliant scopes we utilize the following scopes.
| `urn:zitadel:iam:org:id:{id}` | `urn:zitadel:iam:org:id:178204173316174381` | When requesting this scope **ZITADEL** will enforce that the user is a member of the selected organization. If the organization does not exist a failure is displayed. It will assert the `urn:zitadel:iam:user:resourceowner` claims. |
| `urn:zitadel:iam:org:domain:primary:{domainname}` | `urn:zitadel:iam:org:domain:primary:acme.ch` | When requesting this scope **ZITADEL** will enforce that the user is a member of the selected organization and the username is suffixed by the provided domain. If the organization does not exist a failure is displayed |
| `urn:zitadel:iam:org:roles:id:{orgID}` | `urn:zitadel:iam:org:roles:id:178204173316174381` | This scope can be used one or more times to limit the granted organization IDs in the returned roles. Unknown organization IDs are ignored. When this scope is not used, all granted organizations are returned inside the roles. |
| `urn:zitadel:iam:org:project:id:{projectid}:aud` | `urn:zitadel:iam:org:project:id:69234237810729019:aud` | By adding this scope, the requested projectid will be added to the audience of the access token |
| `urn:zitadel:iam:org:project:id:zitadel:aud` | `urn:zitadel:iam:org:project:id:zitadel:aud` | By adding this scope, the ZITADEL project ID will be added to the audience of the access token |
| `urn:zitadel:iam:org:project:id:{projectid}:aud` | `urn:zitadel:iam:org:project:id:69234237810729019:aud` | By adding this scope, the requested project id will be added to the audience of the access token |
| `urn:zitadel:iam:org:project:id:zitadel:aud` | `urn:zitadel:iam:org:project:id:zitadel:aud` | By adding this scope, the ZITADEL project id will be added to the audience of the access token |
| `urn:zitadel:iam:user:metadata` | `urn:zitadel:iam:user:metadata` | By adding this scope, the metadata of the user will be included in the token. The values are base64 encoded. |
| `urn:zitadel:iam:user:resourceowner` | `urn:zitadel:iam:user:resourceowner` | By adding this scope: id, name and primary_domain of the resource owner (the users organization) will be included in the token. |
| `urn:zitadel:iam:user:resourceowner` | `urn:zitadel:iam:user:resourceowner` | By adding this scope: id, name and primary_domain of the user's organization will be included in the token. |
| `urn:zitadel:iam:org:idp:id:{idp_id}` | `urn:zitadel:iam:org:idp:id:76625965177954913` | By adding this scope the user will directly be redirected to the identity provider to authenticate. Make sure you also send the primary domain scope if a custom login policy is configured. Otherwise the system will not be able to identify the identity provider. |

View File

@@ -103,9 +103,7 @@ curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2beta/actions/executions' \
}
},
"targets": [
{
"target": "<TargetID returned>"
}
"<TargetID returned>"
]
}'
```

View File

@@ -129,9 +129,7 @@ curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2beta/actions/executions' \
}
},
"targets": [
{
"target": "<TargetID returned>"
}
"<TargetID returned>"
]
}'
```

View File

@@ -107,9 +107,7 @@ curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2beta/actions/executions' \
}
},
"targets": [
{
"target": "<TargetID returned>"
}
"<TargetID returned>"
]
}'
```

View File

@@ -154,9 +154,7 @@ curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2beta/actions/executions' \
}
},
"targets": [
{
"target": "<TargetID returned>"
}
"<TargetID returned>"
]
}'
```

View File

@@ -114,9 +114,7 @@ curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2beta/actions/executions' \
}
},
"targets": [
{
"target": "<TargetID returned>"
}
"<TargetID returned>"
]
}'
```

View File

@@ -107,9 +107,7 @@ curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2beta/actions/executions' \
}
},
"targets": [
{
"target": "<TargetID returned>"
}
"<TargetID returned>"
]
}'
```

View File

@@ -173,9 +173,7 @@ curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2beta/actions/executions' \
}
},
"targets": [
{
"target": "<TargetID returned>"
}
"<TargetID returned>"
]
}'
```

View File

@@ -107,9 +107,7 @@ curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2beta/actions/executions' \
}
},
"targets": [
{
"target": "<TargetID returned>"
}
"<TargetID returned>"
]
}'
```

View File

@@ -406,17 +406,11 @@ If you then have a call on `/zitadel.user.v2.UserService/UpdateHumanUser` the fo
And if you use a different service, for example `zitadel.session.v2.SessionService`, then the `all` Execution would still be used.
### Targets and Includes
### Targets
:::info
Includes are limited to 3 levels, which mean that include1->include2->include3 is the maximum for now.
If you have feedback to the include logic, or a reason why 3 levels are not enough, please open [an issue on github](https://github.com/zitadel/zitadel/issues) or [start a discussion on github](https://github.com/zitadel/zitadel/discussions)/[start a topic on discord](https://zitadel.com/chat)
:::
An execution can contain only a list of Targets, and Targets are comma separated string values.
An execution can not only contain a list of Targets, but also Includes.
The Includes can be defined in the Execution directly, which means you include all defined Targets by a before set Execution.
If you define 2 Executions as follows:
Here's an example of a Target defined on a service (e.g. `zitadel.user.v2.UserService`)
```json
{
@@ -426,13 +420,12 @@ If you define 2 Executions as follows:
}
},
"targets": [
{
"target": "<TargetID1>"
}
"<TargetID1>"
]
}
```
Here's an example of a Target defined on a method (e.g. `/zitadel.user.v2.UserService/AddHumanUser`)
```json
{
"condition": {
@@ -441,21 +434,13 @@ If you define 2 Executions as follows:
}
},
"targets": [
{
"target": "<TargetID2>"
},
{
"include": {
"request": {
"service": "zitadel.user.v2.UserService"
}
}
}
"<TargetID2>",
"<TargetID1>"
]
}
```
The called Targets on "/zitadel.user.v2.UserService/AddHumanUser" would be, in order:
The called Targets on `/zitadel.user.v2.UserService/AddHumanUser` would be, in order:
1. `<TargetID2>`
2. `<TargetID1>`

View File

@@ -77,8 +77,8 @@ You can choose from
| Setting | Description |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Unspecified | If nothing is specified the default will trigger. (System settings) |
| Enforce project resource owner policy | This setting will enforce the private labeling of the organization (resource owner) of the project through the whole login process. |
| Allow Login User resource owner policy | With this setting first the private labeling of the organization (resource owner) of the project will trigger. As soon as the user and its organization (resource owner) is identified by ZITADEL, the settings will change to the organization of the user. |
| Enforce project's policy | This setting will enforce the private labeling of the organization of the project through the whole login process. |
| Allow login user policy | With this setting first the private labeling of the organization of the project will trigger. As soon as the user and its organization is identified by ZITADEL, the settings will change to the organization of the user. |
In a B2B use case, you would typically use the organization setting. If you want to omit organization detection, you can preselect an organization with the [primary domain scope](/apis/openidoauth/scopes#reserved-scopes) (ex. `urn:zitadel:iam:org:domain:primary:{domainname}`).

View File

@@ -80,7 +80,7 @@ curl --request POST \
| Field | Type | Description |
| ---------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| org_ids | list of strings | provide a list of organizationIDs to select which organizations should be exported (eg, `[ "70669144072186707", "70671105999825752" ]`); leave empty to export all |
| org_ids | list of strings | provide a list of Organization IDs to select which organizations should be exported (eg, `[ "70669144072186707", "70671105999825752" ]`); leave empty to export all |
| excluded_org_ids | list of strings | to exclude several organization, if for example no organizations are selected |
| with_passwords | bool | to include the hashed_passwords of the users in the export |
| with_otp | bool | to include the OTP-code of the users in the export |
@@ -143,7 +143,7 @@ curl --request POST \
| Field | Type | Description |
| ---------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| org_ids | list of strings | provide a list of organizationIDs to select which organizations should be exported (eg, `[ "70669144072186707", "70671105999825752" ]`); leave empty to export all |
| org_ids | list of strings | provide a list of Organization IDs to select which organizations should be exported (eg, `[ "70669144072186707", "70671105999825752" ]`); leave empty to export all |
| excluded_org_ids | list of strings | to exclude several organization, if for example no organizations are selected |
| with_passwords | bool | to include the hashed_passwords of the users in the export |
| with_otp | bool | to include the OTP-code of the users in the export |

View File

@@ -43,7 +43,7 @@ In order to define the need of the **Portal Application** some planning consider
You can decide whether a organization is preselected for the login or if the user is redirected to the default login screen. Using OpenID Connect, you can send the user to a specific organization by defining the organization in a [reserved scope](/docs/apis/openidoauth/scopes#reserved-scopes) (primary domain).
Settings to the branding or the login options of the organization can be made from the organization section in [Console](/docs/concepts/features/console).
The behavior of the login branding can be set in your projects detail page. You can choose the branding of the selected organization, the user resource owner, or the projects resource owner.
The behavior of the login branding can be set in your projects detail page. You can choose the branding of the selected organization, the user's organization, or the project's organization.
### Organizations

View File

@@ -293,7 +293,7 @@ Excitingly, v3 introduces the foundational elements for Actions V2, opening up a
### v4.x
**Current State**: Implementation
**Current State**: General Availability / Stable
<details>
@@ -311,9 +311,13 @@ Excitingly, v3 introduces the foundational elements for Actions V2, opening up a
This change, along with standardized naming and improved documentation, will simplify integration, accelerate development, and create a more intuitive experience for our customers and community.
Resources integrated in this release:
- Instances
- Applications (in beta)
- Authorizations (in beta)
- Instances (in beta)
- Organizations
- Projects
- Permissions (in beta)
- Projects (in beta)
- Settings (beta) now includes 3 new endpoints: `ListOrganizationSettings()`, `SetOrganizationSettings()` and `DeleteOrganizationSettings()`
- Users
For more details read the [Github Issue](https://github.com/zitadel/zitadel/issues/6305)
@@ -369,40 +373,123 @@ Excitingly, v3 introduces the foundational elements for Actions V2, opening up a
We're officially moving our new Login UI v2 from beta to General Availability.
Starting now, it will be the default login experience for all new customers.
With this release, 8.0we are also focused on implementing previously missing features, such as device authorization and LDAP IDP support, to make the new UI fully feature-complete.
With this release, 8.0 we are also focused on implementing previously missing features, such as device authorization and LDAP IDP support, to make the new UI fully feature-complete.
- [Hosted Login V2](http://localhost:3000/docs/guides/integrate/login/hosted-login#hosted-login-version-2-beta)
- [Hosted Login V2](../guides/integrate/login/hosted-login#hosted-login-version-2-beta)
</details>
<details>
<summary>Web Keys</summary>
<summary>Actions v2</summary>
Web Keys in ZITADEL are used to sign and verify JSON Web Tokens (JWT).
ID tokens are created, signed and returned by ZITADEL when a OpenID connect (OIDC) or OAuth2 authorization flow completes and a user is authenticated.
Based on customer and community feedback, we've updated our key management system. You now have full manual control over key generation and rotation, instead of the previous automatic process.
This API enables you to manage custom executions and targets—formerly known as actions—across your entire ZITADEL instance.
With Actions V2, you gain significantly more flexibility to tailor ZITADELs behavior compared to previous versions.
Actions are now available instance-wide, eliminating the need to configure them for each organization individually.
ZITADEL no longer restricts the implementation language, tooling, or runtime for action executions.
Instead, you define external endpoints that are called by ZITADEL and maintained by you.
Read the full description about Web Keys in our [Documentation](https://zitadel.com/docs/guides/integrate/login/oidc/webkeys).
- [Actions V2](../apis/resources/action_service_v2)
</details>
</details>
<details>
<summary>Deprecated endpoints</summary>
<Deprecated/>
<details>
<summary>Organization Objects V1 > Users V1</summary>
- `AddMachineKey()`
- `AddMachineUser()`
- `AddPersonalAccessToken()`
- `BulkRemoveUserMetadata()`
- `BulkSetUserMetadata()`
- `GenerateMachineSecret()`
- `GetMachineKeyByIDs()`
- `GetOrgByDomainGlobal()`
- `GetPersonalAccessTokenByIDs()`
- `GetUserMetadata()`
- `ListAppKeys()`
- `ListMachineKeys()`
- `ListPersonalAccessTokens()`
- `ListUserMetadata()`
- `RemoveMachineKey()`
- `RemoveMachineSecret()`
- `RemovePersonalAccessToken()`
- `RemoveUserMetadata()`
- `SetUserMetadata()`
- `UpdateHumanPhone()`
- `UpdateMachine()`
- `UpdateUserName()`
</details>
<details>
<summary>SCIM 2.0 Server - User Resource</summary>
<summary>Projects V1</summary>
The Zitadel SCIM v2 service provider interface enables seamless integration of identity and access management (IAM) systems with Zitadel, following the System for Cross-domain Identity Management (SCIM) v2.0 specification.
This interface allows standardized management of IAM resources, making it easier to automate user provisioning and deprovisioning.
- [SCIM 2.0 API](https://zitadel.com/docs/apis/scim2)
- [Manage Users Guide](https://zitadel.com/docs/guides/manage/user/scim2)
- `AddProject()`
- `AddProjectGrant()`
- `AddProjectRole()`
- `BulkAddProjectRoles()`
- `DeactivateProject()`
- `DeactivateProjectGrant()`
- `GetGrantedProjectByID()`
- `GetProjectByID()`
- `GetProjectGrantByID()`
- `ListAllProjectGrants()`
- `ListGrantedProjectRoles()`
- `ListGrantedProjects()`
- `ListProjectGrants()`
- `ListProjectRoles()`
- `ListProjects()`
- `ReactivateProject()`
- `ReactivateProjectGrant()`
- `RemoveProject()`
- `RemoveProjectGrant()`
- `RemoveProjectRole()`
- `UpdateProject()`
- `UpdateProjectGrant()`
- `UpdateProjectRole()`
</details>
<details>
<summary>Caches</summary>
<summary>Members V1</summary>
ZITADEL supports the use of a caches to speed up the lookup of frequently needed objects.
As opposed to HTTP caches which might reside between ZITADEL and end-user applications, the cache build into ZITADEL uses active invalidation when an object gets updated.
Another difference is that HTTP caches only cache the result of a complete request and the built-in cache stores objects needed for the internal business logic.
For example, each request made to ZITADEL needs to retrieve and set instance information in middleware.
- `AddIAMMember()`
- `AddOrgMember()`
- `AddProjectGrantMember()`
- `AddProjectMember()`
- `ListIAMMembers()`
- `ListOrgMembers()`
- `ListProjectGrantMembers()`
- `ListProjectMembers()`
- `ListUserMemberships()`
- `RemoveIAMMember()`
- `RemoveOrgMember()`
- `RemoveProjectGrantMember()`
- `RemoveProjectMember()`
- `UpdateIAMMember()`
- `UpdateOrgMember()`
- `UpdateProjectGrantMember()`
- `UpdateProjectMember()`
</details>
Read more about Zitadel Caches [here](https://zitadel.com/docs/self-hosting/manage/cache)
<details>
<summary>Instance Lifecycle V1 > System Service V1</summary>
- `AddInstanceTrustedDomain()`
- `GetMyInstance()`
- `ListInstanceDomains()`
- `ListInstanceTrustedDomains()`
- `RemoveInstanceTrustedDomain()`
</details>
<details>
<summary>Instance Objects V1 > Organizations V1 </summary>
- `GetDefaultOrg()`
- `GetOrgByID()`
- `IsOrgUnique()`
</details>
</details>

View File

@@ -0,0 +1 @@
login-client-pat

View File

@@ -1,67 +1,65 @@
---
title: Set up ZITADEL with Docker Compose
title: Set up Zitadel with Docker Compose
sidebar_label: Docker Compose
---
import CodeBlock from '@theme/CodeBlock';
import DockerComposeSource from '!!raw-loader!./docker-compose.yaml'
import DockerComposeSaSource from '!!raw-loader!./docker-compose-sa.yaml'
import Disclaimer from './_disclaimer.mdx'
import DefaultUser from './_defaultuser.mdx'
import Next from './_next.mdx'
import NoteInstanceNotFound from './troubleshooting/_note_instance_not_found.mdx';
import ExampleZitadelConfigSource from '!!raw-loader!./example-zitadel-config.yaml'
import ExampleZitadelSecretsSource from '!!raw-loader!./example-zitadel-secrets.yaml'
import ExampleZitadelInitStepsSource from '!!raw-loader!./example-zitadel-init-steps.yaml'
The stack consists of four long-running containers and a couple of short-lived containers:
- A [Traefik](https://doc.traefik.io/traefik/) reverse proxy container with upstream HTTP/2 enabled, issuing a self-signed TLS certificate.
- A Login container that is accessible via Traefik at `/ui/v2/login`
- A Zitadel container that is accessible via Traefik at all other paths than `/ui/v2/login`.
- An insecure [PostgreSQL](https://www.postgresql.org/docs/current/index.html).
The setup is tested against Docker version 20.10.17 and Docker Compose version v2.2.3
The Traefik container and the login container call the Zitadel container via the internal Docker network at `h2c://zitadel:8080`
## Docker compose
The setup is tested against Docker version 28.3.2 and Docker Compose version v2.38.2
By executing the commands below, you will download the following file:
By executing the commands below, you will download the following files:
<details>
<summary>docker-compose.yaml</summary>
<CodeBlock language="yaml">{DockerComposeSource}</CodeBlock>
</details>
<details>
<summary>example-zitadel-config.yaml</summary>
<CodeBlock language="yaml">{ExampleZitadelConfigSource}</CodeBlock>
</details>
<details>
<summary>example-zitadel-secrets.yaml</summary>
<CodeBlock language="yaml">{ExampleZitadelSecretsSource}</CodeBlock>
</details>
<details>
<summary>example-zitadel-init-steps.yaml</summary>
<CodeBlock language="yaml">{ExampleZitadelInitStepsSource}</CodeBlock>
</details>
```bash
# Download the docker compose example configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/docker-compose.yaml
# Run the database and application containers.
docker compose up --detach
# Download and adjust the example configuration file containing standard configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/example-zitadel-config.yaml
# Download and adjust the example configuration file containing secret configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/example-zitadel-secrets.yaml
# Download and adjust the example configuration file containing database initialization configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/example-zitadel-init-steps.yaml
# Make sure you have the latest version of the images
docker compose pull
# Run the containers
docker compose up
```
<DefaultUser components={props.components} />
Open your favorite internet browser at https://localhost/ui/console?login_hint=zitadel-admin@zitadel.localhost.
Your browser warns you about the insecure self-signed TLS certificate. As localhost resolves to your local machine, you can safely proceed.
Use the password *Password1!* to log in.
<NoteInstanceNotFound/>
## VideoGuide
<iframe width="100%" height="315" src="https://www.youtube.com/embed/-02FaoN9Fko" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
## Docker compose with service account
By executing the commands below, you will download the following file:
<details>
<summary>docker-compose-sa.yaml</summary>
<CodeBlock language="yaml">{DockerComposeSaSource}</CodeBlock>
</details>
```bash
# Download the docker compose example configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/docker-compose-sa.yaml -O docker-compose.yaml
# create the machine key directory
mkdir machinekey
# Run the database and application containers.
docker compose up --detach
# then you can move your machine key
mv ./machinekey/zitadel-admin-sa.json $HOME/zitadel-admin-sa.json
```
This key can be used to provision resources with for example [Terraform](/docs/guides/manage/terraform-provider).
<Next components={props.components} />
<Disclaimer components={props.components} />
Read more about [the login process](/guides/integrate/login/oidc/login-users).

View File

@@ -1,49 +0,0 @@
services:
zitadel:
# The user should have the permission to write to ./machinekey
user: "${UID:-1000}"
restart: 'always'
networks:
- 'zitadel'
image: 'ghcr.io/zitadel/zitadel:latest'
command: 'start-from-init --masterkey "MasterkeyNeedsToHave32Characters" --tlsMode disabled'
environment:
ZITADEL_DATABASE_POSTGRES_HOST: db
ZITADEL_DATABASE_POSTGRES_PORT: 5432
ZITADEL_DATABASE_POSTGRES_DATABASE: zitadel
ZITADEL_DATABASE_POSTGRES_USER_USERNAME: zitadel
ZITADEL_DATABASE_POSTGRES_USER_PASSWORD: zitadel
ZITADEL_DATABASE_POSTGRES_USER_SSL_MODE: disable
ZITADEL_DATABASE_POSTGRES_ADMIN_USERNAME: postgres
ZITADEL_DATABASE_POSTGRES_ADMIN_PASSWORD: postgres
ZITADEL_DATABASE_POSTGRES_ADMIN_SSL_MODE: disable
ZITADEL_EXTERNALSECURE: false
ZITADEL_FIRSTINSTANCE_MACHINEKEYPATH: /machinekey/zitadel-admin-sa.json
ZITADEL_FIRSTINSTANCE_ORG_MACHINE_MACHINE_USERNAME: zitadel-admin-sa
ZITADEL_FIRSTINSTANCE_ORG_MACHINE_MACHINE_NAME: Admin
ZITADEL_FIRSTINSTANCE_ORG_MACHINE_MACHINEKEY_TYPE: 1
depends_on:
db:
condition: 'service_healthy'
ports:
- '8080:8080'
volumes:
- ./machinekey:/machinekey
db:
restart: 'always'
image: postgres:17-alpine
environment:
PGUSER: postgres
POSTGRES_PASSWORD: postgres
networks:
- 'zitadel'
healthcheck:
test: ["CMD-SHELL", "pg_isready", "-d", "zitadel", "-U", "postgres"]
interval: '10s'
timeout: '30s'
retries: 5
start_period: '20s'
networks:
zitadel:

View File

@@ -1,41 +1,117 @@
services:
zitadel:
restart: 'always'
networks:
- 'zitadel'
image: 'ghcr.io/zitadel/zitadel:latest'
command: 'start-from-init --masterkey "MasterkeyNeedsToHave32Characters" --tlsMode disabled'
db:
image: postgres:17-alpine
restart: unless-stopped
environment:
ZITADEL_DATABASE_POSTGRES_HOST: db
ZITADEL_DATABASE_POSTGRES_PORT: 5432
ZITADEL_DATABASE_POSTGRES_DATABASE: zitadel
ZITADEL_DATABASE_POSTGRES_USER_USERNAME: zitadel
ZITADEL_DATABASE_POSTGRES_USER_PASSWORD: zitadel
ZITADEL_DATABASE_POSTGRES_USER_SSL_MODE: disable
ZITADEL_DATABASE_POSTGRES_ADMIN_USERNAME: postgres
ZITADEL_DATABASE_POSTGRES_ADMIN_PASSWORD: postgres
ZITADEL_DATABASE_POSTGRES_ADMIN_SSL_MODE: disable
ZITADEL_EXTERNALSECURE: false
- POSTGRES_USER=root
- POSTGRES_PASSWORD=postgres
networks:
- 'storage'
healthcheck:
test: [ "CMD-SHELL", "pg_isready", "-d", "db_prod" ]
interval: 10s
timeout: 60s
retries: 5
start_period: 10s
volumes:
- 'data:/var/lib/postgresql/data:rw'
zitadel-init:
restart: 'no'
networks:
- 'storage'
image: 'ghcr.io/zitadel/zitadel:v4.0.0-rc.2'
command: [ init, --config, /example-zitadel-config.yaml, --config, /example-zitadel-secrets.yaml ]
depends_on:
db:
condition: 'service_healthy'
ports:
- '8080:8080'
volumes:
- './example-zitadel-config.yaml:/example-zitadel-config.yaml:ro'
- './example-zitadel-secrets.yaml:/example-zitadel-secrets.yaml:ro'
db:
restart: 'always'
image: postgres:17-alpine
environment:
PGUSER: postgres
POSTGRES_PASSWORD: postgres
zitadel-setup:
restart: 'no'
networks:
- 'zitadel'
- 'storage'
image: 'ghcr.io/zitadel/zitadel:v4.0.0-rc.2'
command: [ setup, --config, /current-dir/example-zitadel-config.yaml, --config, /current-dir/example-zitadel-secrets.yaml, --steps, /current-dir/example-zitadel-init-steps.yaml, --masterkey, MasterkeyNeedsToHave32Characters ]
depends_on:
zitadel-init:
condition: 'service_completed_successfully'
restart: false
volumes:
- '.:/current-dir:rw'
zitadel:
restart: 'unless-stopped'
networks:
- 'backend'
- 'storage'
labels:
- "traefik.http.routers.zitadel.rule=!PathPrefix(`/ui/v2/login`)"
- "traefik.http.routers.zitadel.tls=true" # Traefik uses a self-signed certificate
- "traefik.http.services.zitadel.loadbalancer.passhostheader=true"
- "traefik.http.services.zitadel.loadbalancer.server.scheme=h2c"
- "traefik.http.services.zitadel.loadbalancer.server.port=8080"
image: 'ghcr.io/zitadel/zitadel:v4.0.0-rc.2'
command: [ start, --config, /example-zitadel-config.yaml, --config, /example-zitadel-secrets.yaml, --masterkey, MasterkeyNeedsToHave32Characters ]
depends_on:
zitadel-setup:
condition: 'service_completed_successfully'
restart: true
volumes:
- './example-zitadel-config.yaml:/example-zitadel-config.yaml:ro'
- './example-zitadel-secrets.yaml:/example-zitadel-secrets.yaml:ro'
healthcheck:
test: ["CMD-SHELL", "pg_isready", "-d", "zitadel", "-U", "postgres"]
interval: '10s'
timeout: '30s'
test: [ "CMD", "/app/zitadel", "ready", "--config", "/example-zitadel-config.yaml", "--config", "/example-zitadel-secrets.yaml" ]
interval: 10s
timeout: 60s
retries: 5
start_period: '20s'
start_period: 10s
login:
restart: 'unless-stopped'
labels:
- "traefik.http.routers.login.rule=PathPrefix(`/ui/v2/login`)"
- "traefik.http.routers.login.tls=true" # Traefik uses a self-signed certificate
- "traefik.http.services.login.loadbalancer.passhostheader=true"
- "traefik.http.services.login.loadbalancer.server.port=3000"
image: 'ghcr.io/zitadel/zitadel-login:v4.0.0-rc.2'
# If you can't use the network_mode service:zitadel, you can pass the environment variable CUSTOM_REQUEST_HEADERS=Host:localhost instead.
network_mode: service:zitadel
environment:
- ZITADEL_API_URL=http://localhost:8080
- NEXT_PUBLIC_BASE_PATH=/ui/v2/login
- ZITADEL_SERVICE_USER_TOKEN_FILE=/current-dir/login-client-pat
user: "${UID:-1000}"
volumes:
- '.:/current-dir:ro'
depends_on:
zitadel-setup:
condition: 'service_completed_successfully'
restart: false
traefik:
image: traefik:latest
command: --providers.docker --api.insecure=true --entrypoints.websecure.address=:443 --log.level=DEBUG --accesslog
networks:
- 'backend'
ports:
- "443:443"
- "8080:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
depends_on:
zitadel:
condition: 'service_healthy'
login:
condition: 'service_started'
networks:
zitadel:
storage:
backend:
volumes:
data:

View File

@@ -1,7 +1,6 @@
# All possible options and their defaults: https://github.com/zitadel/zitadel/blob/main/cmd/defaults.yaml
ExternalSecure: true
ExternalDomain: 127.0.0.1.sslip.io
ExternalPort: 443
# Traefik terminates TLS. Inside the Docker network, we use plain text.
@@ -16,14 +15,8 @@ Database:
User.SSL.Mode: 'disable'
Admin.SSL.Mode: 'disable'
# By default, ZITADEL should redirect to /ui/v2/login
OIDC:
DefaultLoginURLV2: "/ui/v2/login/login?authRequest=" # ZITADEL_OIDC_DEFAULTLOGINURLV2
DefaultLogoutURLV2: "/ui/v2/login/logout?post_logout_redirect=" # ZITADEL_OIDC_DEFAULTLOGOUTURLV2
SAML.DefaultLoginURLV2: "/ui/v2/login/login?authRequest=" # ZITADEL_SAML_DEFAULTLOGINURLV2
# Access logs allow us to debug Network issues
LogStore.Access.Stdout.Enabled: true
# Skipping the MFA init step allows us to immediately authenticate at the console
DefaultInstance.LoginPolicy.MfaInitSkipLifetime: "0s"
DefaultInstance.LoginPolicy.MfaInitSkipLifetime: "0s"

View File

@@ -1,12 +1,11 @@
# All possible options and their defaults: https://github.com/zitadel/zitadel/blob/main/cmd/setup/steps.yaml
FirstInstance:
PatPath: '/pat'
LoginClientPatPath: '/current-dir/login-client-pat'
Org:
# We want to authenticate immediately at the console without changing the password
Human:
PasswordChangeRequired: false
Machine:
Human.PasswordChangeRequired: false
LoginClient:
Machine:
Username: 'login-container'
Name: 'Login Container'
Username: 'login-client'
Name: 'Automatically Initialized IAM Login Client'
Pat.ExpirationDate: '2029-01-01T00:00:00Z'

View File

@@ -1 +0,0 @@
.env-file

View File

@@ -1,157 +0,0 @@
services:
db:
image: postgres:17-alpine
restart: unless-stopped
environment:
- POSTGRES_USER=root
- POSTGRES_PASSWORD=postgres
networks:
- 'storage'
healthcheck:
test: ["CMD-SHELL", "pg_isready", "-d", "db_prod"]
interval: 10s
timeout: 60s
retries: 5
start_period: 10s
volumes:
- 'data:/var/lib/postgresql/data:rw'
zitadel-init:
restart: 'no'
networks:
- 'storage'
image: 'ghcr.io/zitadel/zitadel:latest'
command: 'init --config /example-zitadel-config.yaml --config /example-zitadel-secrets.yaml'
depends_on:
db:
condition: 'service_healthy'
volumes:
- './example-zitadel-config.yaml:/example-zitadel-config.yaml:ro'
- './example-zitadel-secrets.yaml:/example-zitadel-secrets.yaml:ro'
zitadel-setup:
restart: 'no'
networks:
- 'storage'
# We use the debug image so we have the environment to
# - create the .env file for the login to authenticate at Zitadel
# - set the correct permissions for the .env-file folder
image: 'ghcr.io/zitadel/zitadel:latest-debug'
user: root
entrypoint: '/bin/sh'
command:
- -c
- >
/app/zitadel setup
--config /example-zitadel-config.yaml
--config /example-zitadel-secrets.yaml
--steps /example-zitadel-init-steps.yaml
--masterkey ${ZITADEL_MASTERKEY} &&
mv /pat /.env-file/pat || exit 0 &&
echo ZITADEL_SERVICE_USER_TOKEN=$(cat /.env-file/pat) > /.env-file/.env &&
chown -R 1001:${GID} /.env-file &&
chmod -R 770 /.env-file
environment:
- GID
depends_on:
zitadel-init:
condition: 'service_completed_successfully'
restart: false
volumes:
- './.env-file:/.env-file:rw'
- './example-zitadel-config.yaml:/example-zitadel-config.yaml:ro'
- './example-zitadel-secrets.yaml:/example-zitadel-secrets.yaml:ro'
- './example-zitadel-init-steps.yaml:/example-zitadel-init-steps.yaml:ro'
zitadel:
restart: 'unless-stopped'
networks:
- 'backend'
- 'storage'
image: 'ghcr.io/zitadel/zitadel:latest'
command: >
start --config /example-zitadel-config.yaml
--config /example-zitadel-secrets.yaml
--masterkey ${ZITADEL_MASTERKEY}
depends_on:
zitadel-setup:
condition: 'service_completed_successfully'
restart: true
volumes:
- './example-zitadel-config.yaml:/example-zitadel-config.yaml:ro'
- './example-zitadel-secrets.yaml:/example-zitadel-secrets.yaml:ro'
ports:
- "8080:8080"
healthcheck:
test: [
"CMD", "/app/zitadel", "ready",
"--config", "/example-zitadel-config.yaml",
"--config", "/example-zitadel-secrets.yaml"
]
interval: 10s
timeout: 60s
retries: 5
start_period: 10s
# The use-new-login service configures Zitadel to use the new login v2 for all applications.
# It also gives the setupped machine user the necessary IAM_LOGIN_CLIENT role.
use-new-login:
restart: 'on-failure'
user: "1001"
networks:
- 'backend'
image: 'badouralix/curl-jq:alpine'
entrypoint: '/bin/sh'
command:
- -c
- >
curl -X PUT -H "Host: 127.0.0.1.sslip.io" -H "Authorization: Bearer $(cat ./.env-file/pat)" --insecure http://zitadel:8080/v2/features/instance -d '{"loginV2": {"required": true}}' &&
LOGIN_USER=$(curl --fail-with-body -H "Host: 127.0.0.1.sslip.io" -H "Authorization: Bearer $(cat ./.env-file/pat)" --insecure http://zitadel:8080/auth/v1/users/me | jq -r '.user.id') &&
curl -X PUT -H "Host: 127.0.0.1.sslip.io" -H "Authorization: Bearer $(cat ./.env-file/pat)" --insecure http://zitadel:8080/admin/v1/members/$${LOGIN_USER} -d '{"roles": ["IAM_OWNER", "IAM_LOGIN_CLIENT"]}'
volumes:
- './.env-file:/.env-file:ro'
depends_on:
zitadel:
condition: 'service_healthy'
restart: false
login:
restart: 'unless-stopped'
networks:
- 'backend'
image: 'ghcr.io/zitadel/login:main'
environment:
- ZITADEL_API_URL=http://zitadel:8080
- CUSTOM_REQUEST_HEADERS=Host:127.0.0.1.sslip.io
- NEXT_PUBLIC_BASE_PATH="/ui/v2/login"
user: "${UID:-1000}"
volumes:
- './.env-file:/.env-file:ro'
depends_on:
zitadel:
condition: 'service_healthy'
restart: false
traefik:
restart: 'unless-stopped'
networks:
- 'backend'
image: "traefik:latest"
ports:
- "80:80"
- "443:443"
volumes:
- "./example-traefik.yaml:/etc/traefik/traefik.yaml"
depends_on:
zitadel:
condition: 'service_healthy'
login:
condition: 'service_started'
networks:
storage:
backend:
volumes:
data:

View File

@@ -1,40 +0,0 @@
log:
level: DEBUG
accessLog: {}
entrypoints:
websecure:
address: ":443"
providers:
file:
filename: /etc/traefik/traefik.yaml
http:
routers:
login:
entryPoints:
- websecure
service: login
rule: 'Host(`127.0.0.1.sslip.io`) && PathPrefix(`/ui/v2/login`)'
tls: {}
zitadel:
entryPoints:
- websecure
service: zitadel
rule: 'Host(`127.0.0.1.sslip.io`) && !PathPrefix(`/ui/v2/login`)'
tls: {}
services:
login:
loadBalancer:
servers:
- url: http://login:3000
passHostHeader: true
zitadel:
loadBalancer:
servers:
- url: h2c://zitadel:8080
passHostHeader: true

View File

@@ -1,74 +0,0 @@
---
title: A Zitadel Load Balancing Example
---
import CodeBlock from '@theme/CodeBlock';
import DockerComposeSource from '!!raw-loader!./docker-compose.yaml'
import ExampleTraefikSource from '!!raw-loader!./example-traefik.yaml'
import ExampleZITADELConfigSource from '!!raw-loader!./example-zitadel-config.yaml'
import ExampleZITADELSecretsSource from '!!raw-loader!./example-zitadel-secrets.yaml'
import ExampleZITADELInitStepsSource from '!!raw-loader!./example-zitadel-init-steps.yaml'
The stack consists of four long-running containers and a couple of short-lived containers:
- A [Traefik](https://doc.traefik.io/traefik/) reverse proxy container with upstream HTTP/2 enabled, issuing a self-signed TLS certificate.
- A Login container that is accessible via Traefik at `/ui/v2/login`
- A Zitadel container that is accessible via Traefik at all other paths than `/ui/v2/login`.
- An insecure [PostgreSQL](https://www.postgresql.org/docs/current/index.html).
The Traefik container and the login container call the Zitadel container via the internal Docker network at `h2c://zitadel:8080`
The setup is tested against Docker version 28.0.4 and Docker Compose version v2.34.0
By executing the commands below, you will download the following files:
<details>
<summary>docker-compose.yaml</summary>
<CodeBlock language="yaml">{DockerComposeSource}</CodeBlock>
</details>
<details>
<summary>example-traefik.yaml</summary>
<CodeBlock language="yaml">{ExampleTraefikSource}</CodeBlock>
</details>
<details>
<summary>example-zitadel-config.yaml</summary>
<CodeBlock language="yaml">{ExampleZITADELConfigSource}</CodeBlock>
</details>
<details>
<summary>example-zitadel-secrets.yaml</summary>
<CodeBlock language="yaml">{ExampleZITADELSecretsSource}</CodeBlock>
</details>
<details>
<summary>example-zitadel-init-steps.yaml</summary>
<CodeBlock language="yaml">{ExampleZITADELInitStepsSource}</CodeBlock>
</details>
```bash
# Download the docker compose example configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/loadbalancing-example/docker-compose.yaml
# Download the Traefik example configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/loadbalancing-example/example-traefik.yaml
# Download and adjust the example configuration file containing standard configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/loadbalancing-example/example-zitadel-config.yaml
# Download and adjust the example configuration file containing secret configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/loadbalancing-example/example-zitadel-secrets.yaml
# Download and adjust the example configuration file containing database initialization configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/loadbalancing-example/example-zitadel-init-steps.yaml
# A single ZITADEL instance always needs the same 32 bytes long masterkey
# Generate one to a file if you haven't done so already and pass it as environment variable
LC_ALL=C tr -dc '[:graph:]' </dev/urandom | head -c 32 > ./zitadel-masterkey
export ZITADEL_MASTERKEY="$(cat ./zitadel-masterkey)"
# Run the database and application containers
docker compose up --detach --wait
```
Open your favorite internet browser at https://127.0.0.1.sslip.io/ui/console?login_hint=zitadel-admin@zitadel.127.0.0.1.sslip.io.
Your browser warns you about the insecure self-signed TLS certificate. As 127.0.0.1.sslip.io resolves to your localhost, you can safely proceed.
Use the password *Password1!* to log in.
Read more about [the login process](/guides/integrate/login/oidc/login-users).

View File

@@ -0,0 +1,83 @@
---
title: Service Ping
sidebar_label: Service Ping
---
Service Ping is a feature that periodically sends anonymized analytics and usage data from your ZITADEL system to a central endpoint.
This data helps improve ZITADEL by providing insights into its usage patterns.
The feature is enabled by default, but can be disabled either completely or for specific reports.
Checkout the configuration options below.
## Data Sent by Service Ping
### Base Information
If the feature is enabled, the base information will always be sent. To prevent that, you can opt out by disabling the entire Service Ping:
```yaml
ServicePing:
Enabled: false # ZITADEL_SERVICEPING_ENABLED
```
The base information sent back includes the following:
- your systemID
- the currently run version of ZITADEL
- information on all instances
- id
- creation date
- domains
### Resource Counts
Resource counts is a report that provides us with information about the number of resources in your ZITADEL instances.
The following resources are counted:
- Instances
- Organizations
- Projects per organization
- Users per organization
- Instance Administrators
- Identity Providers
- LDAP Identity Providers
- Actions (V1)
- Targets and set up executions
- Login Policies
- Password Complexity Policies
- Password Expiry Policies
- Lockout Policies
The list might be extended in the future to include more resources.
To disable this report, set the following in your configuration file:
```yaml
ServicePing:
Telemetry:
ResourceCounts:
Enabled: false # ZITADEL_SERVICEPING_TELEMETRY_RESOURCECOUNT_ENABLED
```
## Configuration
The Service Ping feature can be configured through the runtime configuration. Please check out the configuration file
for all available options. Below is a list of the most important options:
### Interval
This defines at which interval the Service Ping feature sends data to the central endpoint. It supports the extended cron syntax
and by default is set to `@daily`, which means it will send data every day. The time is randomized on startup to prevent
all systems from sending data at the same time.
You can adjust it to your needs to make sure there is no performance impact on your system.
For example, if you already have some scheduled job syncing data in and out of ZITADEL around a specific time or have regularly a
lot of traffic during the day, you might want to change it to a different time, e.g. `15 4 * * *` to send it every day at 4:15 AM.
The interval must be at least 30 minutes to prevent too frequent requests to the central endpoint.
### MaxAttempts
This defines how many attempts the Service Ping feature will make to send data to the central endpoint before giving up
for a specific interval and report. If one report fails, it will be retried up to this number of times.
Other reports will still be handled in parallel and have their own retry count. This means if the base information
only succeeded after three attempts, the resource count still has five attempts to be sent.

View File

@@ -64,6 +64,5 @@
"@docusaurus/module-type-aliases": "^3.8.1",
"@docusaurus/types": "^3.8.1",
"tailwindcss": "^3.2.4"
},
"packageManager": "pnpm@9.1.2+sha256.19c17528f9ca20bd442e4ca42f00f1b9808a9cb419383cd04ba32ef19322aba7"
}
}
}

View File

@@ -1084,7 +1084,6 @@ module.exports = {
"self-hosting/deploy/devcontainer",
"self-hosting/deploy/knative",
"self-hosting/deploy/kubernetes",
"self-hosting/deploy/loadbalancing-example/loadbalancing-example",
"self-hosting/deploy/troubleshooting/troubleshooting",
],
},
@@ -1118,6 +1117,7 @@ module.exports = {
"self-hosting/manage/tls_modes",
"self-hosting/manage/database/database",
"self-hosting/manage/cache",
"self-hosting/manage/service_ping",
"self-hosting/manage/updating_scaling",
"self-hosting/manage/usage_control",
{

View File

@@ -1,4 +1,4 @@
import React, { Fragment, useContext, useEffect, useState } from "react";
import { Fragment, useContext, useEffect, useState } from "react";
import { AuthRequestContext } from "../utils/authrequest";
import { Listbox } from "@headlessui/react";
import { Transition } from "@headlessui/react";
@@ -111,10 +111,18 @@ export function SetAuthRequest() {
"urn:zitadel:iam:org:project:id:zitadel:aud",
"urn:zitadel:iam:user:metadata",
`urn:zitadel:iam:org:id:${
organizationId ? organizationId : "[organizationId]"
organizationId ? organizationId : "[Organization ID]"
}`,
];
const scopeExplanations = new Map([
['urn:zitadel:iam:org:project:id:zitadel:aud', 'Requested projectid will be added to the audience of the access token.'],
['urn:zitadel:iam:user:metadata', 'Metadata of the user will be included in the token. The values are base64 encoded.'],
[`urn:zitadel:iam:org:id:${
organizationId ? organizationId : "[organizationId]"
}`, 'Enforce that the user is a member of the selected organization.']
]);
const [scopeState, setScopeState] = useState(
[true, true, true, false, false, false, false, false]
// new Array(allScopes.length).fill(false)
@@ -161,8 +169,13 @@ export function SetAuthRequest() {
return input;
};
useEffect(async () => {
setCodeChallenge(await encodeCodeChallenge(codeVerifier));
useEffect(() => {
const updateCodeChallange = async () => {
const newCodeChallange = await encodeCodeChallenge(codeVerifier)
setCodeChallenge(newCodeChallange);
}
updateCodeChallange();
}, [codeVerifier]);
useEffect(() => {
@@ -525,7 +538,7 @@ export function SetAuthRequest() {
const value = event.target.value;
setOrganizationId(value);
allScopes[7] = `urn:zitadel:iam:org:id:${
value ? value : "[organizationId]"
value ? value : "[Organization ID]"
}`;
toggleScope(8, true);
setScope(
@@ -559,6 +572,7 @@ export function SetAuthRequest() {
name="scopes"
value={`${scope}`}
checked={scopeState[scopeIndex]}
disabled={scope === 'openid'}
onChange={() => {
toggleScope(scopeIndex);
}}
@@ -571,6 +585,11 @@ export function SetAuthRequest() {
</strong>
) : null}
</label>
{scopeExplanations.has(scope) && (
<span className={clsx(hintClasses, 'ml-1')}>
{scopeExplanations.get(scope)}
</span>
)}
</div>
);
})}

View File

@@ -4,7 +4,6 @@ import useDocusaurusContext from "@docusaurus/useDocusaurusContext";
import Layout from "@theme/Layout";
import ThemedImage from "@theme/ThemedImage";
import clsx from "clsx";
import React from "react";
import Column from "../components/column";
import {

View File

@@ -1,4 +1,4 @@
import React, { useState, useEffect } from "react";
import React, { useEffect, useState } from "react";
export const AuthRequestContext = React.createContext(null);
@@ -34,7 +34,7 @@ export default ({ children }) => {
const id_token_hint = params.get("id_token_hint");
const organization_id = params.get("organization_id");
setInstance(instance_param ?? "https://mydomain-xyza.zitadel.cloud/");
setInstance(instance_param ?? "http://localhost:8080/");
setClientId(client_id ?? "170086824411201793@yourapp");
setRedirectUri(
redirect_uri ?? "http://localhost:8080/api/auth/callback/zitadel"