andwati/zitadel
1
0
Fork 0
mirror of https://github.com/andwati/zitadel.git synced 2026-10-18 05:52:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: fixed some typos, formatting, grammar (#11540)

Browse Source 
# Which Problems Are Solved

- Typos
- Punctuation
- Markdown table formatting
- ...

(A bunch of issues my editor gave)

# How the Problems Are Solved


# Additional Changes


# Additional Context
This commit is contained in:
Wim Van Laer
2026-02-13 07:45:17 +01:00
committed by GitHub
parent b0609aa861
commit 9b064d8b74
127 changed files with 764 additions and 760 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ADOPTERS.md
+13 -9
View File
@@ -1,15 +1,20 @@
## Adopters
Sharing experiences and learning from other users is essential. We are frequently asked who is using a particular feature of Zitadel so people can get in touch with other users to share experiences and best practices. People also often want to know if a specific product or platform has integrated Zitadel. While the Zitadel Discord Community allows users to get in touch, it can be challenging to find this information quickly.
Sharing experiences and learning from other users is essential. We are frequently asked who is using a particular
feature of Zitadel so people can get in touch with other users to share experiences and best practices. People also
often want to know if a specific product or platform has integrated Zitadel. While the Zitadel Discord Community allows
users to get in touch, it can be challenging to find this information quickly.
The following is a directory of adopters to help identify users of individual features. The users themselves directly maintain the list.
The following is a directory of adopters to help identify users of individual features. The users themselves directly
maintain the list.
### Adding yourself as a user
If you are using Zitadel, please consider adding yourself as a user with a quick description of your use case by opening a pull request to this file and adding a section describing your usage of Zitadel.
If you are using Zitadel, please consider adding yourself as a user with a quick description of your use case by opening
a pull request to this file and adding a section describing your usage of Zitadel.
| Organization/Individual | Contact Information | Description of Usage |
| ----------------------- | -------------------------------------------------------------------- | ----------------------------------------------- |
|-------------------------|---------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Zitadel | [@fforootd](https://github.com/fforootd) (and many more) | Zitadel Cloud makes heavy use of of Zitadel ;-) |
| Rawkode Academy | [@RawkodeAcademy](https://github.com/RawkodeAcademy) | Rawkode Academy Platform & Zulip use Zitadel for all user and M2M authentication |
| XPeditionist | [@XPeditionistTravel](https://github.com/XPeditionistTravel) | An innovative all-in-one travel solution use Zitadel as complete auth solution. |
@@ -19,12 +24,11 @@ If you are using Zitadel, please consider adding yourself as a user with a quick
| Dribdat | [@dribdat](https://github.com/dribdat) | Educating people about strong auth and resilient identity at hackathons |
| Micromate | [@sschoeb](https://github.com/sschoeb) | Using Zitadel for authentication and authorization for learners and managers in our digital learning assistant as well as in the Micromate manage platform |
| Smat.io | [@smatio](https://github.com/smatio) - [@lukasver](https://github.com/lukasver) | Zitadel for authentication in cloud applications while offering B2B portfolio management solutions for professional investors |
|hirschengraben | [hirschengraben.io](hirschengraben.io) | Using Zitadel as IDP for a multitenant B2B dispatch app for bike messengers |
| hirschengraben | [hirschengraben.io](hirschengraben.io) | Using Zitadel as IDP for a multitenant B2B dispatch app for bike messengers |
| OpenAIP | [@openaip](https://github.com/openAIP) | Using Zitadel Cloud for everything related to user authentication. |
| Smat.io | [@smatio](https://github.com/smatio) - [@lukasver](https://github.com/lukasver) | Zitadel for authentication in cloud applications while offering B2B portfolio management solutions for professional investors |
| roclub GmbH | [@holgerson97](https://github.com/holgerson97) | Roclub builds a telehealth application to enable remote MRI/CT examinations. |
| CEEX AG | [@cleanenergyexchange](https://github.com/cleanenergyexchange) | Using Zitadel cloud for our SaaS products that support the sustainabel energy transistion |
| D1V.AI | [d1v.ai](https://d1v.ai) | Powering the *fastest way from prompt to profit*. Zitadel Cloud delivers the secure, scalable user authentication that makes our vibe coding platform possible. |
|  roclub GmbH |  [@holgerson97](https://github.com/holgerson97) |  Roclub builds a telehealth application to enable remote MRI/CT examinations. |
|  CEEX AG |  [@cleanenergyexchange](https://github.com/cleanenergyexchange) |  Using Zitadel cloud for our SaaS products that support the sustainabel energy transistion |
|  D1V.AI |  [d1v.ai](https://d1v.ai) |  Powering the *fastest way from prompt to profit*. Zitadel Cloud delivers the secure, scalable user authentication that makes our vibe coding platform possible. |
| Organization Name | contact@example.com | Description of how they use Zitadel |
| Individual Name | contact@example.com | Description of how they use Zitadel |
README.md
+1 -1
View File
@@ -187,7 +187,7 @@ Use our Login widget to allow easy and secure access to your applications and en
### Management Console
Use [Console](https://zitadel.com/docs/guides/manage/console/console-overview) or our [APIs](https://zitadel.com/docs/apis/introduction) to setup organizations, projects and applications.
Use [Console](https://zitadel.com/docs/guides/manage/console/console-overview) or our [APIs](https://zitadel.com/docs/apis/introduction) to set up organizations, projects and applications.
[![Console Showcase](https://user-images.githubusercontent.com/1366906/223663344-67038d5f-4415-4285-ab20-9a4d397e2138.gif)](http://www.youtube.com/watch?v=RPpHktAcCtk "Console Showcase")
SECURITY.md
+3 -3
View File
@@ -3,7 +3,7 @@
## Introduction
At ZITADEL we are extremely grateful for security aware people who disclose vulnerabilities to us and the open source community.
All reports will be investigated by our team and we will work with you closely to validate and fix vulnerabilities reported to us.
All reports will be investigated by our team, and we will work with you closely to validate and fix vulnerabilities reported to us.
We require that you keep vulnerabilities confidential until we are able to address them, since public disclosure of security vulnerabilities could put the ZITADEL community at risk.
@@ -32,7 +32,7 @@ To file an incident, please disclose it by e-mail to [[email protected]](mail
At the moment GPG encryption is no yet supported, however you may sign your message at will.
Your email will be acknowledged within 48 hours.
We will follow-up within the next 3 business days indicating next steps in handling your report.
We will follow up within the next 3 business days indicating next steps in handling your report.
If you haven't received a response within 48 hours, or you didn't get a reply from our security team within the last 5 days, please contact [[email protected]](mailto:[email protected]).
@@ -41,7 +41,7 @@ We will not publish this information by default to protect your privacy.
### When should I NOT report a vulnerability
- Disclosure of known public files or directories, e.g. robots.txt, files under .well-known, or files that are included in our public repositories (eg, go.mod)
- Disclosure of known public files or directories, e.g. robots.txt, files under .well-known, or files that are included in our public repositories (e.g. `go.mod`)
- DoS of users when [Lockout Policy is enabled](https://zitadel.com/docs/guides/manage/console/default-settings#lockout)
- You need help applying security related settings
apps/docs/README.md
+2 -2
View File
@@ -21,7 +21,7 @@ The site will be available at http://localhost:3000.
Key scripts for documentation workflows:
| Script | Description |
| :--- | :--- |
|:-----------------------|:-----------------------------------------------------------------------------------------------------------------------------|
| `dev` | Starts the development server. |
| `build` | Builds the production application. |
| `fetch:remote-content` | Fetches remote tags and referenced content. |
@@ -37,7 +37,7 @@ Key scripts for documentation workflows:
* **Code Quality**: Run `pnpm lint` to check for syntax and style issues in JS/TS/MDX files.
* **Content Integrity**: Run `pnpm check:links` to validate content structure, including:
* Broken internal links
* Missing required frontmatter (e.g., `title`)
* Missing required front-matter (e.g., `title`)
* Image references
## Contributing
apps/docs/components/PermissionTable/index.jsx
+2 -2
View File
@@ -1,9 +1,9 @@
import React, { useMemo } from 'react';
import yaml from 'js-yaml';
import { Check, X } from 'lucide-react';
import { cn } from '@/utils/cn'; // Assuming utils/cn exists or I'll use clsx/tailwind-merge directly if not sure
import { cn } from '@/utils/cn'; // Assuming utils/cn exists, or I'll use clsx/tailwind-merge directly if not sure
// Fallback utility if generic cn doesn't exist, checking imports first is safer but I'll inline a simple merge if needed
// Fallback utility if generic cn doesn't exist, checking imports first is safer, but I'll inline a simple merge if needed
// Checking package.json I saw clsx and tailwind-merge are dependencies.
function classNames(...classes) {
apps/docs/components/version-selector.tsx
+1 -1
View File
@@ -20,7 +20,7 @@ export function VersionSelector() {
// Handle basePath issues: usePathname() typically returns path relative to basePath if configured?
// But purely relying on that is tricky. Let's normalize.
// If pathname starts with /docs, assume it's the full path and we strip it for logic,
// If pathname starts with /docs, assume it's the full path, and we strip it for logic,
// then let router handle re-adding it if needed (or we check behaviors).
// Actually, Next.js router.push() expects path relative to basePath usually?
// Let's implement robust segment swapping.
apps/docs/content/apis/actions/external-authentication.mdx
+1 -1
View File
@@ -91,7 +91,7 @@ The trigger is represented by the following Ids in the API: `TRIGGER_TYPE_PRE_CR
- `setLastName(string)`
Sets the last name
- `setNickName(string)`
Sets the nick name
Sets the nickname
- `setDisplayName(string)`
Sets the display name
- `setPreferredLanguage(string)`
apps/docs/content/apis/actions/internal-authentication.mdx
+1 -1
View File
@@ -58,7 +58,7 @@ The trigger is represented by the following Ids in the API: `TRIGGER_TYPE_PRE_CR
- `setLastName(string)`
Sets the last name
- `setNickName(string)`
Sets the nick name
Sets the nickname
- `setDisplayName(string)`
Sets the display name
- `setPreferredLanguage(string)`
apps/docs/content/apis/actions/introduction.mdx
+1 -1
View File
@@ -18,7 +18,7 @@ Actions are a key feature to extend the functionality of ZITADEL and continuousl
The action object describes the logic defined by the user. Actions can be linked to multiple [triggers](#flows).
The name of the action must corelate with the javascript function in the code section. This function will be called by ZITADEL.
The name of the action must correlate with the JavaScript function in the code section. This function will be called by ZITADEL.
For reading and mutating state, the runtime executes the function that has the same name as the action.
The function receives the JavaScript objects `ctx` and `api`.
apps/docs/content/apis/actions/objects.mdx
+4 -4
View File
@@ -7,7 +7,7 @@ title: Objects
- `externalId` *string*
User id from the identity provider
- `externalIdpId` *string*
Id of the identity provider
ID of the identity provider
- `human`
- `firstName` *string*
- `lastName` *string*
@@ -44,7 +44,7 @@ title: Objects
## user grant
- `projectID` *string*
Required. Id of the project to be granted
Required. ID of the project to be granted
- `projectGrantID` *string*
Optional. If the grant is for a project grant, include projectGrantID
- `roles` Array of *string*
@@ -57,7 +57,7 @@ title: Objects
- `changeDate` *Date*
- `resourceOwner` *string*
- `sequence` *number*
Unsigned 64 bit integer
Unsigned 64-bit integer
- `state` *number*
<ul><li>0: unspecified</li><li>1: active</li><li>2: inactive</li><li>3: deleted</li><li>4: locked</li><li>5: suspended</li><li>6: initial</li></ul>
- `username` *string*
@@ -182,7 +182,7 @@ This object represents [the claims](../openidoauth/claims) which will be written
- `email_verified` *bool*
- `updated_at` *Number*
Additionally there could additional fields depending on the configuration of your [project](../../guides/manage/console/projects-overview#role-settings) and your [application](../../guides/manage/console/applications-overview#token-settings)
Additionally, there could be fields depending on the configuration of your [project](../../guides/manage/console/projects-overview#role-settings) and your [application](../../guides/manage/console/applications-overview#token-settings)
## user grant list
apps/docs/content/apis/benchmarks/index.mdx
+4 -3
View File
@@ -3,13 +3,14 @@ title: Benchmarks
sidebar_label: Benchmarks
---
import DocCardList from '@/components/docusaurus/doc-card-list';
Benchmarks are crucial to understand if ZITADEL fulfills your expected workload and what resources it needs to do so.
This document explains the process and goals of load-testing zitadel in a cloud environment.
The results can be found on sub pages.
The results can be found on sub-pages.
## Goals
@@ -41,9 +42,9 @@ The tests must at least measure the request duration for each API call. This giv
The following metrics must be collected for each test iteration. The metrics are used to follow the decision path of the [After test procedure](https://drive.google.com/open?id=1WVr7aA8dGgV1zd2jUg1y1h_o37mkZF2O6M5Mhafn_NM):
| Metric | Type | Description | Unit |
| :---- | :---- | :---- | :---- |
|:--------------------------------------|:------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | Comparison | Defines the baseline the test is compared against. If not specified the baseline defined in this document is used. | Link to test result |
| Purpose | Description | Description what should been proved with this test run | text
| Purpose | Description | Description what should been proved with this test run | text |
| Test start | Setup | Timestamp when the test started. This is useful for gathering additional data like metrics or logs later | Date |
| Test duration | Setup | Duration of the test | Duration |
| Executed test | Setup | Name of the make recipe executed. Further information about specific test cases can be found [here](?tab=t.0#heading=h.xav4f3s5r2f3). | Name of the make recipe |
apps/docs/content/apis/benchmarks/v2.65.0/machine_jwt_profile_grant/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ Tests are halted after this test run because of too many [client read events](ht
## Performance test results
| Metric | Value |
| :---- | :---- |
|:--------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Test start | 22-10-2024 16:20 UTC |
| Test duration | 30min |
apps/docs/content/apis/benchmarks/v2.66.0/machine_jwt_profile_grant/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ The tests showed heavy database load by time by the first two database queries.
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 15:39 UTC |
apps/docs/content/apis/benchmarks/v2.70.0/machine_jwt_profile_grant/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ The performance goals of [this issue](https://github.com/zitadel/zitadel/issues/
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 09:48 UTC |
apps/docs/content/apis/benchmarks/v2.70.0/oidc_session/index.mdx
+1 -1
View File
@@ -13,7 +13,7 @@ The tests showed that querying the user takes too much time because Zitadel ensu
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 14:24 UTC |
apps/docs/content/apis/benchmarks/v4/add_session/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ Benchmark results of v4 release of Zitadel.
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 11:31 UTC |
apps/docs/content/apis/benchmarks/v4/human_password_login/index.mdx
+1 -1
View File
@@ -13,7 +13,7 @@ This benchmark tests the flow of a user signing in to Zitadel using username and
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 06:43 UTC |
apps/docs/content/apis/benchmarks/v4/introspect/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ Benchmark results of v4 release of Zitadel.
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 13:33 UTC |
apps/docs/content/apis/benchmarks/v4/machine_client_credentials_login/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ Benchmark results of v4 release of Zitadel.
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 08:28 UTC |
apps/docs/content/apis/benchmarks/v4/machine_jwt_profile_grant/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ Benchmark results of v4 release of Zitadel.
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 18:33 UTC |
apps/docs/content/apis/benchmarks/v4/machine_pat_login/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ Benchmark results of v4 release of Zitadel.
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 07:34 UTC |
apps/docs/content/apis/benchmarks/v4/manipulate_user/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ Benchmark results of v4 release of Zitadel.
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 15:07 UTC |
apps/docs/content/apis/benchmarks/v4/otp_session/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ Benchmark results of v4 release of Zitadel.
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 14:56 UTC |
apps/docs/content/apis/benchmarks/v4/password_session/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ Benchmark results of v4 release of Zitadel.
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 15:14 UTC |
apps/docs/content/apis/benchmarks/v4/user_info/index.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ Benchmark results of v4 release of Zitadel.
## Performance test results
| Metric | Value |
|:--------------------------------------|:------|
|:--------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 16:06 UTC |
apps/docs/content/apis/migration_v1_to_v2.mdx
+2 -2
View File
@@ -61,7 +61,7 @@ It effectively replaces the previous REST gateway.
For teams already using gRPC, your transition will be minimal.
For teams who were using the v1 REST API, migrating to v2 will involve adopting one of the following methods:
- Native gRPC: For the highest performance and to leverage features like bi-directional streaming.
- Native gRPC: For the highest performance and to leverage features like bidirectional streaming.
- Connect RPC: For making CRUD-like (Create, Read, Update, Delete) calls over HTTP. This is the recommended path for most applications migrating from our v1 REST API.
A significant advantage of this new architecture remains the automatic generation of client libraries.
@@ -147,7 +147,7 @@ The biggest change is in how you create/update applications.
Instead of calling a specific endpoint for each type (e.g., CreateOidcApp, CreateSamlApp), you will now use a single CreateApp endpoint.
To specify the type of application, you will include its specific configuration object within the request body.
For example, to create a OIDC app, you will provide a oidc object in the request.
For example, to create a OIDC app, you will provide an oidc object in the request.
All properties that are common to every application, such as name, are now top-level fields in the request body, consistent across all types.
This approach simplifies client-side logic, as you no longer need to route requests to different endpoints.
apps/docs/content/apis/observability/metrics.mdx
+2 -2
View File
@@ -7,9 +7,9 @@ ZITADEL provides a `metrics` endpoint with the help of the [opentelemetry-go](ht
If you are self-hosting ZITADEL, you can access this endpoint with on the path `/debug/metrics`.
For example when running ZITADEL locally the endpoint is accessible on `http://localhost:8080/debug/metrics`.
The metrics endpoint can be scrubbed by any tool of choice that supports the `otel` format, e.g an existing Prometheus.
The metrics endpoint can be scrubbed by any tool of choice that supports the `otel` format, e.g. an existing Prometheus.
For our [Kubernetes/Helm](/self-hosting/deploy/kubernetes) users, we provide an out of the box support for the [ServiceMonitor](https://github.com/zitadel/zitadel-charts/blob/main/charts/zitadel/templates/servicemonitor.yaml) custom resource.
For our [Kubernetes/Helm](/self-hosting/deploy/kubernetes) users, we provide an out-of-the-box support for the [ServiceMonitor](https://github.com/zitadel/zitadel-charts/blob/main/charts/zitadel/templates/servicemonitor.yaml) custom resource.
By default, metrics are enabled but can be turned off through ZITADEL's [configuration](/self-hosting/manage/configure).
The (default) configuration is located in the [defaults.yaml](https://github.com/zitadel/zitadel/blob/main/cmd/defaults.yaml).
apps/docs/content/apis/openidoauth/_token_exchange_request.mdx
+1 -1
View File
@@ -1,5 +1,5 @@
| Parameter | Description |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|
| grant_type | Must be `urn:ietf:params:oauth:grant-type:token-exchange` |
| subject_token | A token that represents the identity of the party on behalf of whom the request is being made. |
| subject_token_type | An identifier that indicates the type of the token in the subject_token parameter. |
apps/docs/content/apis/openidoauth/_token_exchange_response.mdx
+1 -1
View File
@@ -1,5 +1,5 @@
| Property | Description |
| ----------------- | ------------------------------------------------------------------------------------ |
|-------------------|--------------------------------------------------------------------------------------|
| access_token | An `access_token` as opaque token or JWT for the subject user |
| token_type | Type of the `access_token`. Value can be `Bearer` or `N_A` |
| issued_token_type | [Token type](#token-types) of the returned token, matches the `requested_token_type` |
apps/docs/content/apis/openidoauth/_token_exchange_types.mdx
+1 -1
View File
@@ -1,7 +1,7 @@
The following table provides a matrix of supported token type parameter and responses for Token Exchange.
| Identifier | subject_token | actor_token | requested_token_type |
| ------------------------------------------------ | ------------------------------------------------------------ | ------------- | -------------------- |
|--------------------------------------------------|--------------------------------------------------------------|---------------|----------------------|
| `urn:ietf:params:oauth:token-type:access_token` | JWT or Opaque | JWT or Opaque | Opaque only |
| `urn:ietf:params:oauth:token-type:refresh_token` | Not allowed | Not allowed | Not allowed |
| `urn:ietf:params:oauth:token-type:id_token` | Allowed | Allowed | Allowed |
apps/docs/content/apis/openidoauth/authn-methods.mdx
+1 -1
View File
@@ -45,7 +45,7 @@ Key JSON
JWT
| Claim | Example | Description |
|:------|:---------------------------|:----------------------------------------------------------------------------------------------------------------|
|:------|:-----------------------------|:----------------------------------------------------------------------------------------------------------------|
| aud | `"https://${CUSTOM_DOMAIN}"` | String or Array of intended audiences MUST include ZITADEL's issuing domain |
| 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 |
apps/docs/content/apis/openidoauth/authrequest.mdx
+2 -2
View File
@@ -15,7 +15,7 @@ An OpenID Connect (OIDC) [authentication request](https://openid.net/specs/openi
## Why this OIDC playground?
Currently ZITADEL requires human users to authenticate trough the hosted login page.
Currently, ZITADEL requires human users to authenticate through the hosted login page.
Your application should initiate a login by issuing an authentication request and redirecting the user to the login page. You can customize the behavior of ZITADEL by providing additional parameters and scopes in the request.
This playground should help you to initially craft an authentication request and to explore the behavior of ZITADEL in more depth.
@@ -117,7 +117,7 @@ Please refer to the full [guide on branding](/guides/manage/customize/branding).
Pass the scope `urn:zitadel:iam:user:metadata` to request a user's metadata.
Please refer to the full [guide on user-metadata](/guides/manage/customize/user-metadata) for further details.
### Access core apis
### Access core APIs
Calling the [core API](/apis/introduction) with the authenticated user, requires that the projectID of ZITADEL is included in the audience claim.
apps/docs/content/apis/openidoauth/claims.mdx
+1 -1
View File
@@ -107,7 +107,7 @@ https://github.com/zitadel/actions/blob/main/examples/custom_roles.js#L20-L33
ZITADEL reserves some claims to assert certain data. Please check out the [reserved scopes](./scopes#reserved-scopes).
| Claims | Example | Description |
|:--------------------------------------------------|:---------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|:--------------------------------------------------|:---------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| urn:zitadel:iam:action:\{actionname}:log | `{"urn:zitadel:iam:action:appendCustomClaims:log": ["test log", "another test log"]}` | This claim is set during Actions as a log, e.g. if two custom claims with the same keys are set. |
| urn:zitadel:iam:org:domain:primary:\{domainname} | `{"urn:zitadel:iam:org:domain:primary": "acme.ch"}` | This claim represents the primary domain of the organization the user belongs to. |
| 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 application belongs to). |
apps/docs/content/apis/openidoauth/grant-types.mdx
+3 -3
View File
@@ -6,7 +6,7 @@ sidebar_label: Grant Types
For a list of supported or unsupported `Grant Types` please have a look at the table below.
| Grant Type | Supported |
| :---------------------------------------------------- | :-------- |
|:------------------------------------------------------|:----------|
| Authorization Code | yes |
| Authorization Code with PKCE | yes |
| Client Credentials | yes |
@@ -57,7 +57,7 @@ Our service user work with the JWT profile to authenticate them against ZITADEL.
Key JSON
| Key | Example | Description |
| :----- | :------------------------------------------------------------------ | :----------------------------------------------------------------- |
|:-------|:--------------------------------------------------------------------|:-------------------------------------------------------------------|
| 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! |
@@ -77,7 +77,7 @@ Key JSON
JWT
| Claim | Example | Description |
| :---- | :------------------------- | :------------------------------------------------------------------------------------------------------------ |
|:------|:-----------------------------|:--------------------------------------------------------------------------------------------------------------|
| aud | `"https://${CUSTOM_DOMAIN}"` | String or Array of intended audiences MUST include ZITADEL's issuing domain |
| 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 |
apps/docs/content/apis/openidoauth/scopes.mdx
+2 -2
View File
@@ -8,7 +8,7 @@ ZITADEL supports the usage of scopes as way of requesting information from the i
## Standard Scopes
| Scopes | Description |
| :------------- | ------------------------------------------------------------------------------ |
|:---------------|--------------------------------------------------------------------------------|
| openid | When using openid connect this is a mandatory scope |
| profile | Optional scope to request the profile of the subject |
| email | Optional scope to request the email of the subject |
@@ -21,7 +21,7 @@ ZITADEL supports the usage of scopes as way of requesting information from the i
In addition to the standard compliant scopes we utilize the following scopes.
| Scopes | Example | Description |
| :------------------------------------------------ | :----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|:--------------------------------------------------|:-------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `urn:zitadel:iam:org:project:role:{rolekey}` | `urn:zitadel:iam:org:project:role:user` | By using this scope a client can request the claim `urn:zitadel:iam:org:project:roles` to be asserted when possible. As an alternative approach you can enable all roles to be asserted from the [project](/guides/manage/console/roles#authorizations) a client belongs to. |
| `urn:zitadel:iam:org:projects:roles` | `urn:zitadel:iam:org:projects:roles` | By using this scope a client can request the claim `urn:zitadel:iam:org:project:{projectid}:roles` to be asserted for each requested project. All projects of the token audience, requested by the `urn:zitadel:iam:org:project:id:{projectid}:aud` scopes will be used. |
| `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. |
apps/docs/content/concepts/architecture/software.mdx
+7 -7
View File
@@ -17,7 +17,7 @@ This All in One (AiO) approach makes operating Zitadel simple.
## The Architecture
Zitadels software architecture is built around multiple components at different levels.
Zitadel's software architecture is built around multiple components at different levels.
This chapter should give you an idea of the components as well as the different layers.
![](../../../public/img/zitadel_software_architecture.png)
@@ -63,7 +63,7 @@ The Command Side has some unique requirements, these include:
The command handler receives all operations who alter a resource managed by Zitadel.
For example if a user changes their name. The API Layer will pass the instruction received through the API call to the command handler for further processing.
The command handler is then responsible of creating the necessary commands.
The command handler is then responsible for creating the necessary commands.
After creating the commands the command hand them down to the command validation.
##### Command Validation
@@ -76,7 +76,7 @@ These events now are being handed down to the storage layer for storage.
#### Events
Zitadel handles events in two ways.
Events that should be processed in near real time are processed by a in memory pub sub system.
Events that should be processed in near real time are processed by an in memory pub sub system.
Some events can be handled asynchronously using the spooler.
##### Pub Sub
@@ -103,7 +103,7 @@ Spoolers are especially necessary where someone can query datasets instead of si
#### Projections
Projections are responsible of normalizing data for the query side or for analytical purpose.
Projections are responsible for normalizing data for the query side or for analytical purpose.
They generally work by being invoked either through a scheduled spooler or the pub sub subscription.
When they receive events they will create their normalized object and then store this into the query view and its storage layer.
@@ -122,10 +122,10 @@ It has some unique requirements, which include:
##### Query Handler
The query handler receives all read relevant operations. These can either be query or simple `getById` calls.
The query handler receives all read relevant operations. These can either be queries or simple `getById` calls.
When receiving a query it will proceed by passing this to the repository which will call the database and return the dataset.
If a request calls for a specific id the call will, most of the times, be revalidated against the Event Store.
This is achieved by triggering the projection to make sure that the last sequence of a id is loaded into the query view.
If a request calls for a specific id the call will, most of the time, be revalidated against the Event Store.
This is achieved by triggering the projection to make sure that the last sequence of an id is loaded into the query view.
> The query side has the option to dynamically check the Event Store for newer events on a certain id to make sure for consistent responses without delay.
apps/docs/content/concepts/eventstore/implementation.mdx
+12 -12
View File
@@ -9,22 +9,22 @@ The goal is to give you a rough overview, so you know where which data is stored
## Event
The single source of truth of ZITADEL are the events that are stored in the eventstore.
From these events all different kind of resources e.g Users, Projects, Applications, etc. can be computed.
From these events all different kind of resources e.g. Users, Projects, Applications, etc. can be computed.
An event has the following data:
| Attribute | Description | Example |
| --- | --- | --- |
|----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------|
| id | unique identifier of the event, this is generated by the database | b6402a60-e4655-4cc0-904b-f5c6760c4406 |
| aggregate_type | the type of the aggregate, an aggregate can be compared to a resource or an object. One aggregate contains multiple event types | user |
| aggregate_id | The unique identifier of an aggregate, this is generated by ZITADEL and is a sonyflake id | 168096909691353697 |
| aggregate_version | The aggregate version shows in which version of the aggregate the event was created. This is needed to be able to compute correct objects | v1 |
| event_type | The type of the event | user.human.added |
| event_sequence | The event sequence is a sequence number that is incremented by one for each event on the instance. For technical reasons, a number can be omitted in some cases. This is needed so that the sequence of the events can be ensured. | 1234 |
| previous_aggregate_sequence| This number is the sequence of the event last created on this specific aggregate. E.g. Last user with specific aggregate_id | 1233|
| previous_aggregate_sequence | This number is the sequence of the event last created on this specific aggregate. E.g. Last user with specific aggregate_id | 1233 |
| previous_aggregate_type_sequence | This number is the sequence of the event last created on this aggregate. E.g Last User | 1230 |
| creation_date| timestamp when the event was created | 2022-07-05 13:57:56.358774+00 |
| editor_user| The editor user contains mostly an unique identifier of a user. And tells who did the request that led to this event. Sometimes this can also be a name of a system within ZITADEL. | 165460784409638965, NOTIFICATION, LOGIN |
| creation_date | timestamp when the event was created | 2022-07-05 13:57:56.358774+00 |
| editor_user | The editor user contains mostly an unique identifier of a user. And tells who did the request that led to this event. Sometimes this can also be a name of a system within ZITADEL. | 165460784409638965, NOTIFICATION, LOGIN |
| editor_service | The service defines which API was called when the event got created. If the event was created from the system itself this is empty. | Admin-API |
| resource_owner | The resource owner defines to which organization/resource_owner the event belongs. This is an id generated by ZITADEL as sonyflake id | 168051083313153168 |
| instance_id | ZITADEL is capable of containing multiple ZITADEL instances withing the system. This id is the unique identifier of the Instance and is generated by ZITADEL as sonyflake id. | 165460784409737865 |
@@ -32,13 +32,13 @@ An event has the following data:
## Schemas
| Schema | Description | Examples |
| --- | --- | --- |
|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------|
| System | The system contains everything that is needed outside the ZITADEL instances. | assets, encryption_key |
| Eventstore | Eventstore is the base of ZITADEL and is the single source of truth. All the events stored in the eventstore can be used to generate different projections. | events, instance sequences, system wide unique constraints
| Projections| The projections contain all the computed objects which are used for reading requests. | users, projects, etc|
| Eventstore | Eventstore is the base of ZITADEL and is the single source of truth. All the events stored in the eventstore can be used to generate different projections. | events, instance sequences, system wide unique constraints |
| Projections | The projections contain all the computed objects which are used for reading requests. | users, projects, etc |
| Auth | This contains projections which are used for the auth api. All projections in this schema should be moved to Projections soon | users, auth_request, etc. |
| Adminapi | This contains projections which are used for the admin api. All projections in this schema should be moved to Projections soon | styling|
| Notification | This contains projections which are used for sending notification. All projections in this schema should be moved to Projections soon | styling|
| Adminapi | This contains projections which are used for the admin api. All projections in this schema should be moved to Projections soon | styling |
| Notification | This contains projections which are used for sending notification. All projections in this schema should be moved to Projections soon | styling |
## Projections
@@ -65,7 +65,7 @@ You can find the current sequence in the following tables:
The current sequence is stored for each ZITADEL instance and table.
| Attribute | Description | Examples |
| --- | --- | --- |
|------------------|-------------------------------------------------------------|-------------------------------|
| projection_name | The name of the projection for which the sequence is valid. | projection.users |
| aggregate_type | The aggregate type where the sequence was from | user |
| current_sequence | The sequence that was last processed | 1234 |
@@ -86,7 +86,7 @@ You can find the failed_events in the following tables:
- adminapi.failed_events
| Attribute | Description | Examples |
| --- | --- | --- |
|-----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------|
| projection_name | The name of the projection for which the failed event should have been processed. | projection.users |
| failed_sequence | The sequence of the event that failed | 1234 |
| failure_count | The number of times the event was attempted to be processed. If the number is lower than the max. attempts the event could be processed, but not on the first attempt | 5 |
apps/docs/content/concepts/features/audit-trail.mdx
+6 -6
View File
@@ -3,16 +3,16 @@ title: ZITADEL's In-built Audit Trail
sidebar_label: Audit Trail
---
ZITADEL provides you with an built-in audit trail to track all changes and events over an unlimited period of time.
Most other solutions replace a historic record and track changes in a separate log when information is updated.
ZITADEL only ever appends data in an [Eventstore](/concepts/eventstore/overview), keeping all historic record.
ZITADEL provides you with a built-in audit trail to track all changes and events over an unlimited period of time.
Most other solutions replace a historical record and track changes in a separate log when information is updated.
ZITADEL only ever appends data in an [Eventstore](/concepts/eventstore/overview), keeping all historical record.
The audit trail itself is identical to the state, since ZITADEL calculates the state from all the past changes.
![](../../../public/img/concepts/audit-trail/audit-log-events.png)
This form of audit log has several benefits over storing classic audit logs.
You can view past data in-context of the whole system at a single point in time.
Reviewing a past state of the application can be important when tracing an incident that happened months back. Moreover the eventstore provides a truly complete and clean audit log.
Reviewing a past state of the application can be important when tracing an incident that happened months back. Moreover, the eventstore provides a truly complete and clean audit log.
<Callout title="Future Plans">
There will be three major areas for future development on the audit data
@@ -28,7 +28,7 @@ There will be three major areas for future development on the audit data
### Last changes of an object
You can check the last changes of most objects in the [Console](/guides/manage/console/console-overview).
In the following screenshot you can see an example of last changes on an [user](/guides/manage/console/users-overview).
In the following screenshot you can see an example of last changes on a [user](/guides/manage/console/users-overview).
The same view is available on several other objects such as organization or project.
![](../../../public/img/guides/console/myprofile.png)
@@ -42,7 +42,7 @@ Go to your default settings and then click on the Tab **Events** to open the Eve
### Event API
Since everything that is available in Management Console can also be called with our APIs, you can access all events and audit data trough our APIs:
Since everything that is available in Management Console can also be called with our APIs, you can access all events and audit data through our APIs:
- [Event API Guide](/guides/integrate/zitadel-apis/event-api)
- [API Documentation](/reference/api/admin)
apps/docs/content/concepts/features/identity-brokering.mdx
+5 -5
View File
@@ -3,7 +3,7 @@ title: Identity Brokering
sidebar_label: Identity Brokering
---
Link social logins and external identity providers with your identity management platform allowing users to login with their preferred identity provider.
Link social logins and external identity providers with your identity management platform allowing users to log in with their preferred identity provider.
Establish a trusted connection between your central identity provider (IdP) and third party identity providers.
@@ -26,7 +26,7 @@ A service provider that specializes in brokering access control between multiple
Federated identity management is an arrangement that is made between two or more such identity brokers across organizations.
For example, if Google is configured as an identity provider in your organization, the user will get the option to use his Google Account on the Login Screen of ZITADEL.
Because Google is registered as a trusted identity provider, the user will be able to login in with the Google account after the user is linked with an existing ZITADEL account (if the user is already registered) or a new one with the claims provided by Google.
Because Google is registered as a trusted identity provider, the user will be able to log in with the Google account after the user is linked with an existing ZITADEL account (if the user is already registered) or a new one with the claims provided by Google.
![](../../../public/img/concepts/features/identity-brokering.png)
@@ -41,9 +41,9 @@ The schema is a very simplified version, but shows the essential steps for ident
## Is single-sign-on (SSO) the same as identity brokering?
Sometimes single-sign-on (SSO) and login with third party identity providers is used interchangeably.
Typically SSO describes an authentication scheme that allows users to log in once at a central identity provider and access service providers (client applications) without to login again.
Typically, SSO describes an authentication scheme that allows users to log in once at a central identity provider and access service providers (client applications) without having to login again.
Identity brokering describes an authentication scheme where users can login with external identity providers that have a established trust with an identity provider which facilitates the authentication for the requested applications.
Identity brokering describes an authentication scheme where users can log in with external identity providers that have an established trust with an identity provider which facilitates the authentication for the requested applications.
The connection between the two lies in how SSO can be implemented as part of an identity brokering solution.
In such cases, the identity broker uses SSO to enable seamless access across multiple systems, handling the complexities of different authentication protocols and standards behind the scenes.
@@ -52,7 +52,7 @@ This allows users to log in once and gain access to multiple systems that the br
## Multitenancy and identity brokering
In a multi-tenancy application, you want to be able to configure an external identity provider per tenant.
For example some organizations might use their EntraID, some other want to login with their OKTA, or Google Workspace.
For example some organizations might use their EntraID, some other want to log in with their OKTA, or Google Workspace.
Using an identity provider with strong multitenancy capabilities such as ZITADEL, you can configure a different set of external identity providers per organization.
apps/docs/content/concepts/principles.mdx
+1 -1
View File
@@ -8,7 +8,7 @@ title: Principles
- Embrace stateless application design
- System of records is the event store
- Everything else needs to be able to be regenerated
- Try not so solve complex problems outside of the IAM Domain
- Try not to solve complex problems outside the IAM Domain
- Use a scalable storage for the event store and read models
- Try to be idempotent whenever possible
- Reduce necessity of external systems or dependencies as much as possible
apps/docs/content/concepts/structure/instance.mdx
+2 -2
View File
@@ -8,7 +8,7 @@ sidebar_label: Instances
An instance is the top node in ZITADEL's data hierarchy.
Within an instance all the default [settings](/concepts/structure/policies),
such as branding, login policy, password policy, etc. for the system can be configured.
One instance normally runs on one domain and represents one issuer (e.g login.customer.com).
One instance normally runs on one domain and represents one issuer (e.g. login.customer.com).
One instance can contain multiple [organizations](/guides/manage/console/organizations-overview),
which in turn can represent your own company (e.g. departments), your business customers or a consumer organization.
@@ -25,7 +25,7 @@ You will find more detailed explanations around the different concepts in the fo
ZITADEL has the concept of virtual instances.
When installing ZITADEL from scratch, one instance is always automatically created for you.
Nevertheless, you can add more virtual instances via the [system API](/reference/api/system).
This is useful if you have business customers, which in turn have their business customers with self service and Custom Domain demands.
This is useful if you have business customers, which in turn have their business customers with self-service and Custom Domain demands.
By providing a virtual ZITADEL instances, your customers have all the customization options available in ZITADEL.
Scaling ZITADEL instances virtually enables you to easily distribute your limited compute resources to all your customers.
apps/docs/content/concepts/structure/users.mdx
+3 -3
View File
@@ -19,9 +19,9 @@ Read more on how to [login users with ZITADEL](/guides/integrate/login/login-use
### Service users
Service users are for machine-to-machine communication and you would use those typically to access secure backend services.
Service users are for machine-to-machine communication, and you would use those typically to access secure backend services.
For example in ZITADEL you would require an authenticated Service User to access the Management API.
The main difference between users and service accounts is the type of credentials that can be used for authentication: users typically logon via an login prompt, but service accounts require a non-interactive logon process.
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.
@@ -33,7 +33,7 @@ A user with an administrator role is not only an end-user of ZITADEL but can als
### Federated users
Federated users are identities that are managed by a third-party identity provider.
Users can login via an external identity provider, using [identity brokering](../features/identity-brokering) ("Single-sign-on").
Users can log in via an external identity provider, using [identity brokering](../features/identity-brokering) ("Single-sign-on").
Federated user [accounts are linked](../features/account-linking) to internal users to be able to assign roles and keep an audit trail.
### External users
apps/docs/content/examples/imports/_serviceuser_jwt.mdx
+1 -1
View File
@@ -26,7 +26,7 @@
![](../../../public/img/examples/secure-api/service-user-jwt/7.png)
8. You will see the following screen afterwards.
8. You will see the following screen afterward.
![](../../../public/img/examples/secure-api/service-user-jwt/8.png)
apps/docs/content/examples/imports/_serviceuser_role.mdx
+1 -1
View File
@@ -31,6 +31,6 @@ In order to access this route, you must create the role `read:messages` in your
![](../../../public/img/examples/secure-api/service-user-jwt/scopes/8.png)
9. You will now see the your service user has been assigned the role **read:messages**.
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)
apps/docs/content/examples/login/angular.mdx
+1 -1
View File
@@ -66,7 +66,7 @@ Copy the following code to your service. This code provides a function `authenti
https://github.com/zitadel/zitadel-angular/blob/main/src/app/services/authentication.service.ts
```
Our example includes a _StatehandlerService_ that redirects the user back to the route from which they initially came.If you don't need such behavior, you can omit the following line from the `authenticate()` method above.
Our example includes a _StatehandlerService_ that redirects the user back to the route from which they initially came. If you don't need such behavior, you can omit the following line from the `authenticate()` method above.
```ts reference
https://github.com/zitadel/zitadel-angular/blob/main/src/app/services/authentication.service.ts#L45
apps/docs/content/examples/login/nextjs-b2b.mdx
+12 -12
View File
@@ -29,30 +29,30 @@ Enter the name `Demo-Vendor`, and click "Create". Then click on that organizatio
### Portal Web Application
To setup this sample you have to create a project and an application in the vendor organization (`Demo-Vendor`) first.
To set up this sample you have to create a project and an application in the vendor organization (`Demo-Vendor`) first.
Open the Management Console (`https://$CUSTOM_DOMAIN.zitadel.cloud/ui/console/projects`) and create a new project. Let's call it `Portal`.
Then on the project detail page click on new application and enter a name for this app.
Let's call this one `portal-web`.
Select `Web`, continue, `CODE`, then enter `http://localhost:3000/api/auth/callback/zitadel` for the redirect, and `http://localhost:3000` for the post redirect. Then press on `create`.
Because the requests from your NextJS application to ZITADEL are made on the server side, you can safely select `CODE`. You will get a secret at the end of the stepper. With NextAuth your secret never gets exposed on the browser since it is kept in your NextJS server.
Because the requests from your Next.js application to ZITADEL are made on the server side, you can safely select `CODE`. You will get a secret at the end of the stepper. With NextAuth your secret never gets exposed on the browser since it is kept in your Next.js server.
Copy the "Resource Id" of the project `Portal` as you will need this in your environment configuration file later.
Copy the "Resource ID" of the project `Portal` as you will need this in your environment configuration file later.
Click on the application `portal-web`.
On the application detail page click on the section under redirect settings and enable `Development Mode`. This will allow you application to work on `localhost:3000`.
To read the user data and roles from ID Token, go to the section Token Settings and make sure both checkboxes, `User roles inside ID Token` and `User Info inside ID Token` are enabled.
Make sure to save your changes.
Copy the "Resource Id" of the application `portal-web` as you will need this in your environment configuration file later.
Copy the "Resource ID" of the application `portal-web` as you will need this in your environment configuration file later.
### Roles
To setup the needed roles for your project, navigate to your `Portal` project, and add the following roles
To set up the needed roles for your project, navigate to your `Portal` project, and add the following roles
| Key | Display Name | Group | Description |
| :----- | :------------ | :---- | ---------------------------------------------------------------------- |
|:-------|:--------------|:------|------------------------------------------------------------------------|
| admin | Administrator | | The administrator, allowed to read granted projects and to user grants |
| reader | Reader | | A user who is allowed to read his organizations granted projects only |
@@ -77,7 +77,7 @@ To show granted projects, go to the `Demo-Vendor` organization and add the Servi
## Configuration
Now clone this project and navigate to its root folder.
Create a file `.env.local` and copy paste the following:
Create a file `.env.local` and copy and paste the following:
```text
NEXTAUTH_URL=http://localhost:3000
@@ -96,13 +96,13 @@ Replace the values as follows
`NEXT_PUBLIC_ZITADEL_ISSUER`: The url to your zitadel instance. When using zitadel.cloud for this demo you can find the domain of your ZITADEL instance in the customer portal. You can also find this information by going to your application `portal-web` and click 'URLs' in the navigation. The variable is prefixed with `NEXT_PUBLIC_` such that it can be accessed from the application.
`ZITADEL_API`: URL of the Management API. Typically the same as `ZITADEL_ISSUER`.
`ZITADEL_API`: URL of the Management API. Typically, the same as `ZITADEL_ISSUER`.
`ORG_ID`: We will create an organization during later steps. You can find `${YOUR_ORG_ID}` by selecting the `Demo-Vendor` organization in Console. `${YOUR_ORG_ID}` is displayed on top of the organization detail page as "Resource Id".
`ORG_ID`: We will create an organization during later steps. You can find `${YOUR_ORG_ID}` by selecting the `Demo-Vendor` organization in Console. `${YOUR_ORG_ID}` is displayed on top of the organization detail page as "Resource ID".
`PROJECT_ID`: You can find `${PROJECT_ID}` by clicking on "Projects" in the navigation and select the Project `Portal`. `${PROJECT_ID}` is displayed on the top as "Resource Id".
`PROJECT_ID`: You can find `${PROJECT_ID}` by clicking on "Projects" in the navigation and select the Project `Portal`. `${PROJECT_ID}` is displayed on the top as "Resource ID".
`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, labelled "Client ID" and has the format `12345678@portal`.
`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).
@@ -165,7 +165,7 @@ Give `Alice Admin` the roles `reader` and `admin`.
### Login
You should be able to login to the Demo Application with `Alice Admin` and see all granted projects.
You should be able to log in to the Demo Application with `Alice Admin` and see all granted projects.
You can log out and log in with `Eric Employee` and you should only have access to the granted projects, but not to the Authorizations tab.
apps/docs/content/examples/secure-api/go.mdx
+2 -2
View File
@@ -58,7 +58,7 @@ On the user view, switch to *Service Users* and create a new one.
![](../../../public/img/go/api-service_user_panel.png)
Give the service user a name and a user name. Select `Bearer` as *Access Token Type*.
Give the service user a name and a username. Select `Bearer` as *Access Token Type*.
![](../../../public/img/go/api-create_service_user.png)
@@ -91,7 +91,7 @@ Create a new go file with the content below. This will create an API with three
If authorization is required, the token must not be expired and the API has to be part of the audience (either client_id or project_id).
For tests we will use a Personal Access Token.
For tests, we will use a Personal Access Token.
```go reference
https://github.com/zitadel/zitadel-go/blob/next/example/api/http/main.go
apps/docs/content/guides/integrate/external-audit-log.mdx
+1 -1
View File
@@ -18,7 +18,7 @@ ZITADEL provides different solutions how to send events to external systems, the
The following table shows the available integration patterns for streaming audit logs to external systems.
| | Description | Self-hosting | ZITADEL Cloud |
|-------------------------------------|----------------------------------------------------------------------------------------------------------------|-------------|---------------|
|-------------------------------------|----------------------------------------------------------------------------------------------------------------|--------------|---------------|
| Events-API | Pulling events of all ZITADEL resources such as Users, Projects, Apps, etc. (Events = Change Log of Resources) | ✅ | ✅ |
| ZITADEL Actions Log to Stdout | Custom log to messages possible on predefined triggers during login / register Flow | ✅ | ❌ |
| ZITADEL Actions trigger API/Webhook | Custom API/Webhook request on predefined triggers during login / register | ✅ | ✅ |
apps/docs/content/guides/integrate/identity-providers/apple.mdx
+1 -1
View File
@@ -59,7 +59,7 @@ You will have to paste it in the Apple service later.
Go back [to the Apple provider template you opened before in ZITADEL](#open-the-apple-identity-provider-template).
1. Add the Client ID, this is [the identifier of the service you created in your Apple Account](#register-a-new-service)
2. Fill the Team ID, you can find it when you login to your Apple Developer account, in your membership
2. Fill the Team ID, you can find it when you log in to your Apple Developer account, in your membership
3. Enter the [Key ID and upload the Private Key you created before](#register-a-new-key)
You can optionally configure the following settings.
apps/docs/content/guides/integrate/identity-providers/azure-ad-oidc.mdx
+3 -3
View File
@@ -28,7 +28,7 @@ You need to have access to an Entra ID Tenant. If you do not yet have one follow
### Register a new application
1. Browse to the [App registration menus create dialog](https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/CreateApplicationBlade/quickStartType~/null/isMSAApp~/false) to create a new app.
2. Give the application a name and choose who should be able to login (Single-Tenant, Multi-Tenant, Personal Accounts, etc.) This setting will also have an impact on how to configure the provider later on in ZITADEL.
2. Give the application a name and choose who should be able to log in (Single-Tenant, Multi-Tenant, Personal Accounts, etc.) This setting will also have an impact on how to configure the provider later on in ZITADEL.
3. Choose "Web" in the redirect uri field and [paste the ZITADEL Callback URL you copied before](#open-the-microsoft-identity-provider-template).
4. Save the Application (client) ID and the Directory (tenant) ID from the detail page
5. Register the application
@@ -42,7 +42,7 @@ You need to have access to an Entra ID Tenant. If you do not yet have one follow
Generate a new client secret to authenticate your user.
1. Click on client credentials on the detail page of the application or use the menu "Certificates & secrets"
2. Click on "+ New client secret" and enter a description and an expiry date, add the secret afterwards
2. Click on "+ New client secret" and enter a description and an expiry date, add the secret afterward
3. Copy the value of the secret. You will not be able to see the value again after some time
![](../../../../public/img/guides/azure_client_secret.png)
@@ -84,7 +84,7 @@ If you want to avoid that, make sure to enable "Email verified".
In that case, the user is created with a verified email address.
**Tenant Type**: Configure the tenant type according to what you have chosen in the settings of your Entra ID application previously.
- Common: Choose common if you want all Microsoft accounts being able to login.
- Common: Choose common if you want all Microsoft accounts being able to log in.
In this case, configure "Accounts in any organizational directory and personal Microsoft accounts" in your Entra ID App.
- Organizations: Choose organization if you have Entra ID Tenants and no personal accounts. (You have configured either "Accounts in this organization" or "Accounts in any organizational directory" on your Azure APP)
- Consumers: Choose this if you want to allow public accounts. (In your Entra ID App you have configured "Personal Microsoft accounts only")
apps/docs/content/guides/integrate/login-ui/_list-mfa-options.mdx
+2 -2
View File
@@ -1,4 +1,4 @@
Your user has successfully authenticated, and now you ask them if they want to setup MFA to have a more secure account.
Your user has successfully authenticated, and now you ask them if they want to set up MFA to have a more secure account.
When the user starts the configuration, first you want to show them the possible methods.
You can either list it implicitly or call the settings service from ZITADEL to get what is configured on the login settings.
@@ -14,7 +14,7 @@ curl --request GET \
```
Response Example:
The relevant part for the list is the second factor and multi-factor list.
The relevant part for the list is the second factor and multifactor list.
```bash
{
apps/docs/content/guides/integrate/login/oidc/device-authorization.mdx
+3 -3
View File
@@ -13,14 +13,14 @@ This documentation aims to guide you through the process of seamlessly integrati
## Why Integrate with Zitadel?
ZITADEL offers a comprehensive identity and access management solution, providing features like single sign-on (SSO), multi-factor authentication (MFA), user management, and more. By integrating your application with ZITADEL, you can leverage these powerful features to enhance the security and usability of your application without reinventing the wheel.
ZITADEL offers a comprehensive identity and access management solution, providing features like single sign-on (SSO), multifactor authentication (MFA), user management, and more. By integrating your application with ZITADEL, you can leverage these powerful features to enhance the security and usability of your application without reinventing the wheel.
## Getting Started
To begin integrating your application with Zitadel using RFC 8628, follow the steps outlined in this documentation. We'll walk you through the process, from setting up your application in the Zitadel management console to handling user authentication and access tokens in your application code.
1. Go to “Organization”/”Projects”.
2. Under “Applications” click the “New” button.
1. Go to "Organization"/"Projects".
2. Under "Applications" click the "New" button.
<img src="/docs/img/device-auth/device-auth-01.png" alt="Device Authorization Flow in ZITADEL"/>
apps/docs/content/guides/integrate/login/oidc/logout.mdx
+6 -6
View File
@@ -10,12 +10,12 @@ This guide shows you the different concepts and use cases of the logout process
### Single Sign On (SSO) vs Single Logout (SLO)
Single Sign On (SSO) allows a user to login once without the need for authentication across multiple applications.
Single Logout (SLO) is the counterpart to SSO. With SLO a user can logout and terminate sessions across many applications, without actively logging out from them.
Single Logout (SLO) is the counterpart to SSO. With SLO a user can log out and terminate sessions across many applications, without actively logging out from them.
The purpose of a logout is to terminate a user session.
Depending on how the session handling is implemented, there are different mechanisms that can be used.
There are two possibilities where sessions are stored:
- The User Agent (e.g the Browser or Mobile App) stores the session information (e.g. in a cookie)
- The User Agent (e.g. the Browser or Mobile App) stores the session information (e.g. in a cookie)
- A Server stores the session information (e.g. in a database or api)
### OpenID Connect Logout
@@ -27,14 +27,14 @@ OpenID Connect defines three logout mechanisms to address the different architec
#### Session Management
Session Management in OpenID Connect defines a mechanism for a client (Relying Party, RP) to monitor the state of the user session from a identity provider (OP, e.g ZITADEL).
Session Management in OpenID Connect defines a mechanism for a client (Relying Party, RP) to monitor the state of the user session from an identity provider (OP, e.g. ZITADEL).
When a user logs out of the provider, the user's session is terminated and the client can in turn reflect that in its behavior.
#### RP initiated Logout
With the RP initiated flow all logout processes are triggered by a request from the client (e.g your application) through a well defined standard API by redirecting the user-agent to the [end_session_endpoint](/apis/openidoauth/endpoints#end-session-endpoint).
With the RP initiated flow all logout processes are triggered by a request from the client (e.g. your application) through a well-defined standard API by redirecting the user-agent to the [end_session_endpoint](/apis/openidoauth/endpoints#end-session-endpoint).
If you have specified some post_logout_redirect_uris on your client you have to send either the id_token_hint or the client_id as param in your request.
So ZITADEL is able to read the configured redirect uris.
So ZITADEL is able to read the configured redirect URIs.
```
GET ${CUSTOM_DOMAIN}/oidc/v1/end_session
@@ -55,7 +55,7 @@ This is not yet implemented in ZITADEL
#### Back-Channel Logout
The back-channel logout is a mechanism on the server-side and the user agent does not have to do anything.
The user will logout from all clients even in the case the user agent was closed.
The user will log out from all clients even in the case the user agent was closed.
<Callout>
This is not yet implemented in ZITADEL
apps/docs/content/guides/integrate/login/oidc/oauth-recommended-flows.mdx
+5 -5
View File
@@ -7,11 +7,11 @@ sidebar_label: Recommended authorization flows
In this guide we will go over some basics on how to obtain an authorization with OpenID Connect 1.x and OAuth 2.x.
ZITADEL does not make assumptions about the application type you are about to integrate. Therefore you must qualify and define an appropriate method for your users to gain authorization to access your application (“authentication flow”). Your choice depends on the application’s ability to maintain the confidentiality of client credentials and the technological capabilities of your application. If you choose a deprecated or unfeasible flow to obtain authorization for your application, your users’ credentials may be compromised.
ZITADEL does not make assumptions about the application type you are about to integrate. Therefore, you must qualify and define an appropriate method for your users to gain authorization to access your application (“authentication flow”). Your choice depends on the application’s ability to maintain the confidentiality of client credentials and the technological capabilities of your application. If you choose a deprecated or unfeasible flow to obtain authorization for your application, your users’ credentials may be compromised.
We invite you to further explore the different authorization flows in the OAuth 2.x standard. For the start we assume that you have a brand-new application (ie. without legacy requirements) and you found an reliable SDK/Library that does the heavy lifting for you.
We invite you to further explore the different authorization flows in the OAuth 2.x standard. For the start we assume that you have a brand-new application (i.e. without legacy requirements) and you found a reliable SDK/Library that does the heavy lifting for you.
So this module will only go over the basics and explain why we recommend the flow “Authorization Flow with PKCE” as default for most applications. We will also cover the case of machine-to-machine communication, ie. where there is no interactive login. Further we will guide you to further reading viable alternatives, if the default flow is not feasible.
So this module will only go over the basics and explain why we recommend the flow “Authorization Flow with PKCE” as default for most applications. We will also cover the case of machine-to-machine communication, i.e. where there is no interactive login. Further we will guide you to further reading viable alternatives, if the default flow is not feasible.
## Basics of Federated Identity
@@ -28,12 +28,12 @@ So what do we want to achieve with delegated authentication?
- Instead of implementing authentication on each server and trusting each server
- Users only **authenticate** with a trusted server (ie. ZITADEL), that validates the user’s identity through a challenge (eg, multiple authentication factors) and issues an **ID token** (OpenID Connect 1.x)
- Users only **authenticate** with a trusted server (i.e. ZITADEL), that validates the user’s identity through a challenge (eg, multiple authentication factors) and issues an **ID token** (OpenID Connect 1.x)
- Applications have means of **validating the integrity** of presented access and ID tokens
- Instead of sending around the user’s credentials
- Clients may access protected resources with an **access token** that is only valid for specific scope and limited lifetime (OAuth 2.x)
- Users have to **authorize** applications to access certain [**scopes**](/apis/openidoauth/scopes) (eg, email address or custom roles). Applications can request [**claims**](/apis/openidoauth/claims) (key:value pairs, eg email address) for the authorized scopes with the access token or ID token from ZITADEL
- Users have to **authorize** applications to access certain [**scopes**](/apis/openidoauth/scopes) (eg, email address or custom roles). Applications can request [**claims**](/apis/openidoauth/claims) (key:value pairs, e.g. email address) for the authorized scopes with the access token or ID token from ZITADEL
- Access tokens are bearer tokens, meaning that possession of the token provides access to a resource. But the tokens expire frequently and the application must request a new access token via **refresh token** or the user must reauthenticate
![](../../../../../public/img/guides/consulting_federated_identities_basics.png)
apps/docs/content/guides/integrate/login/oidc/webkeys.mdx
+16 -16
View File
@@ -26,7 +26,7 @@ ZITADEL implements the [RFC7517 - JSON Web Key (JWK)](https://www.rfc-editor.org
Web keys in ZITADEL support a number of [JSON Web Algorithms (JWA)](https://www.rfc-editor.org/rfc/rfc7518) for digital signatures:
| Identifier | Description |
| ---------- | ------------------------------- |
|------------|---------------------------------|
| RS256 | RSASSA-PKCS1-v1_5 using SHA-256 |
| RS384 | RSASSA-PKCS1-v1_5 using SHA-384 |
| RS512 | RSASSA-PKCS1-v1_5 using SHA-512 |
@@ -73,7 +73,7 @@ Since the decision in the proposal isn't published yet,
there is a big change some OIDC client libraries don't have proper support for EdDSA / ed25519.
The ZITADEL back-end is written in Go. The Go developers have denied ed448 curve implementations to be included.
Therefore ZITADEL only uses ed25519 with a SHA512.
Therefore, ZITADEL only uses ed25519 with a SHA512.
The same counts for [zitadel/oidc](https://github.com/zitadel/oidc) Go library.
## Web Key management
@@ -127,7 +127,7 @@ The RSA generator config takes two enum values.
- `RSA_HASHER_SHA384` results in the RS384 algorithm header.
- `RSA_HASHER_SHA512` results in the RS512 algorithm header.
For example, to create a RSA web key with the size of 3072 bits and the SHA512 algorithm (RS512):
For example, to create an RSA web key with the size of 3072 bits and the SHA512 algorithm (RS512):
```bash
curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
@@ -175,7 +175,7 @@ Note that the `alg` header for ed25519 is `EdDSA` and refers to both ed25519 and
Both curves specify different hashers.
Clients which support both curves must inspect `crv` header value to assert the difference.
For example, to create a ed25519 web key:
For example, to create an ed25519 web key:
```bash
curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
@@ -188,7 +188,7 @@ curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
```
[^2]: The ZITADEL back-end is written in Go. The Go developers have denied ed448 curve implementations to be included.
Therefore ZITADEL won't support this either.
Therefore, ZITADEL won't support this either.
### Activation
@@ -198,7 +198,7 @@ There can be only one active key on an instance.
Activating a key implies deactivation of the previously active key.
Public keys on the [JWKS](#json-web-key-set) endpoint may be [cached](#caching).
Therefore it is advised to delay activation after generating a key,
Therefore, it is advised to delay activation after generating a key,
at least for the duration of the max-age setting plus any time it might take for client applications to refresh.
### Deletion
@@ -207,8 +207,8 @@ Non-active keys may be [deleted](/apis/resources/webkey_service_v2/zitadel-webke
Deletion also means tokens signed with this key become invalid.
Active keys can't be deleted.
As each public key is available on the [JWKS](#json-web-key-set) endpoint,
it is important to cleanup old web keys that are no longer needed.
Otherwise the endpoint's response size will only grow over time, which might lead to performance issues.
it is important to clean up old web keys that are no longer needed.
Otherwise, the endpoint's response size will only grow over time, which might lead to performance issues.
Once a key was activated and deactivated (by activation of the next key) deletion should wait:
@@ -224,14 +224,14 @@ This strategy aims to fulfill the following requirements:
1. Web keys are rotated monthly.
2. Applications have enough time to see the next activated web key on the [JWKS](#json-web-key-set) endpoint.
3. Web keys are kept long enough to cover the access and ID token validity of 24 hours.
4. Web keys are kept long enough to to allow usage of the `id_token_hint` for at least 3 months.
4. Web keys are kept long enough to allow usage of the `id_token_hint` for at least 3 months.
Users that haven't logged in / refreshed tokens with the client application for that period,
will need to re-enter their username.
When the instance was created, resp. the feature was rolled out, the instance got two keys with the first one activated. When this feature becomes generally available, instance creation will setup the first two keys in the same way. So the initial state always looks like this:
When the instance was created, resp. the feature was rolled out, the instance got two keys with the first one activated. When this feature becomes generally available, instance creation will set up the first two keys in the same way. So the initial state always looks like this:
| id | created | changed | state |
| --- | ---------- | ---------- | --------------- |
|----|------------|------------|-----------------|
| 1 | 2025-01-01 | 2025-01-01 | `STATE_ACTIVE` |
| 2 | 2025-01-01 | 2025-01-01 | `STATE_INITIAL` |
@@ -254,7 +254,7 @@ curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
Key ID 2 became active, Key ID 1 became inactive and a new key with ID 3 was created:
| id | created | changed | state |
| --- | ---------- | ---------- | ---------------- |
|----|------------|------------|------------------|
| 1 | 2025-01-01 | 2025-02-01 | `STATE_INACTIVE` |
| 2 | 2025-01-01 | 2025-02-01 | `STATE_ACTIVE` |
| 3 | 2025-02-01 | 2025-02-01 | `STATE_INITIAL` |
@@ -264,7 +264,7 @@ We continue like this monthly.
At one point (on 2025-05-01) we will have a web key with `STATE_INACTIVE` with a changed date of 3 months ago:
| id | created | changed | state |
| --- | ---------- | ---------- | ---------------- |
|----|------------|------------|------------------|
| 1 | 2025-01-01 | 2025-02-01 | `STATE_INACTIVE` |
| 2 | 2025-01-01 | 2025-03-01 | `STATE_INACTIVE` |
| 3 | 2025-02-01 | 2025-04-01 | `STATE_INACTIVE` |
@@ -284,14 +284,14 @@ curl -L -X DELETE 'https://${CUSTOM_DOMAIN}/v2/web_keys/1' \
The final state:
| id | created | changed | state |
| --- | ---------- | ---------- | ---------------- |
|----|------------|------------|------------------|
| 2 | 2025-01-01 | 2025-03-01 | `STATE_INACTIVE` |
| 3 | 2025-02-01 | 2025-04-01 | `STATE_INACTIVE` |
| 4 | 2025-03-01 | 2025-05-01 | `STATE_INACTIVE` |
| 5 | 2025-04-01 | 2025-05-01 | `STATE_ACTIVE` |
| 6 | 2025-05-01 | 2025-05-01 | `STATE_INITIAL` |
Next month, Key ID 6 will be activated, an new key added and Key ID 2 can be deleted.
Next month, Key ID 6 will be activated, a new key added and Key ID 2 can be deleted.
## JSON web key set
@@ -340,7 +340,7 @@ The legacy keys will disappear once they expire.
As web keys can be created and distributed ahead of time, it is safe for JWKS responses to be cached at intermediate proxies.
Once the `web_key` feature is enabled, ZITADEL will send a `Cache-Control` header which allows caching.
By default and in ZITADEL Cloud we allow 5 minutes of caching:
By default, and in ZITADEL, Cloud we allow 5 minutes of caching:
```
Cache-Control: max-age=300, must-revalidate
apps/docs/content/guides/integrate/onboarding/_org_login_description.mdx
+1 -1
View File
@@ -1,5 +1,5 @@
Per default the login ui of the default organization is shown.
To allow users of a specific organization to register with their IDP (e.g Entra ID) you have two options.
To allow users of a specific organization to register with their IDP (e.g. Entra ID) you have two options.
1. Identify organization with organization scope
apps/docs/content/guides/integrate/service-accounts/personal-access-token.mdx
+1 -1
View File
@@ -12,7 +12,7 @@ It is an alternative to the [private key JWT](./private-key-jwt) and [client cre
1. Navigate to Service Users
2. Click on **New**
3. Enter a user name and a display name
3. Enter a username and a display name
4. Click on the Personal Access Token menu point in the detail of your user
5. Click on **New**
6. You can either set an expiration date or leave it empty if you don't want it to expire
apps/docs/content/guides/integrate/services/atlassian-saml.mdx
+1 -1
View File
@@ -89,7 +89,7 @@ Add members to your policy.
Now you should be all set to verify your setup:
- Create an user in ZITADEL with the same email address as a member in your authentication policy.
- Create a user in ZITADEL with the same email address as a member in your authentication policy.
- In a new browser session go to https://id.atlassian.com
- Enter the user's email address
- You should be redirected to ZITADEL's Login screen
apps/docs/content/guides/integrate/services/auth0-oidc.mdx
+4 -4
View File
@@ -19,7 +19,7 @@ Prerequisites:
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
- existing Auth0 tenant as described [here](https://auth0.com/docs/get-started/auth0-overview/create-tenants)
> We have to switch between ZITADEL and a Auth0. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and if the headings start with "Auth0" please switch to the Auth0 GUI.
> We have to switch between ZITADEL and Auth0. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and if the headings start with "Auth0" please switch to the Auth0 GUI.
## **Auth0**: Create a new connection
@@ -45,8 +45,8 @@ First of all we create the application in your project.
## **Auth0**: Connect ZITADEL
1. Copy the client id from ZITADEL and past it into the **Client ID** field
2. Copy the client secret from ZITADEL and past it into the **Client Secret** field
1. Copy the client id from ZITADEL and paste it into the **Client ID** field
2. Copy the client secret from ZITADEL and paste it into the **Client Secret** field
![](../../../../public/img/oidc/auth0/auth0-full.png)
3. click Create
4. To verify the connection go to the "Applications" tab and enable the Default App
@@ -54,6 +54,6 @@ First of all we create the application in your project.
5. Click "Back to OpenID Connect"
6. Click on the "..." button right to the newly created connection and click "Try"
![](../../../../public/img/oidc/auth0/auth0-try.png)
7. ZITADEL should open on a new tab and you can enter your login information
7. ZITADEL should open on a new tab, and you can enter your login information
8. After you logged in you should see the following:
![](../../../../public/img/oidc/auth0/auth0-works.png)
apps/docs/content/guides/integrate/services/auth0-saml.mdx
+2 -2
View File
@@ -17,7 +17,7 @@ Prerequisites:
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
- existing Auth0 tenant as described [here](https://auth0.com/docs/get-started/auth0-overview/create-tenants)
> We have to switch between ZITADEL and a Auth0. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and
> We have to switch between ZITADEL and Auth0. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and
> if the headings start with "Auth0" please switch to the Auth0 GUI.
## **Auth0**: Create a new connection
@@ -70,7 +70,7 @@ Everything on the side of ZITADEL is done if the application is correctly create
## **Auth0**: Try the connection
To then test the connection you only have to press "Try" on the created connection in the Authentication -> Enterprise
To then test the connection you only have to press "Try" on the created connection in the Authentication → Enterprise
screen.
![](../../../../public/img/saml/auth0/auth_enterprise_try.png)
apps/docs/content/guides/integrate/services/aws-saml.mdx
+3 -3
View File
@@ -18,7 +18,7 @@ Prerequisites:
- prerequisites on AWS side [here](https://docs.aws.amazon.com/singlesignon/latest/userguide/prereqs.html).
- enabled AWS SSO [here](https://docs.aws.amazon.com/singlesignon/latest/userguide/step1.html?icmpid=docs_sso_console)
> We have to switch between ZITADEL and a AWS. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and if
> We have to switch between ZITADEL and AWS. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and if
> the headings start with "AWS" please switch to the AWS GUI.
## **AWS**: Change to external identity provider ZITADEL
@@ -33,7 +33,7 @@ can connect to ZITADEL as a SAML2 IDP.
![](../../../../public/img/saml/aws/change_idp.png)
2. Download the metadata file, to provide ZITADEL with all the information it needs, and save the AWS SSO Sign-in URL,
which you use to login afterwards.
which you use to log in afterward.
3. Fill out the fields as follows, to provide AWS with all the information it needs:
![](../../../../public/img/saml/aws/configure_idp.png)
@@ -75,5 +75,5 @@ Everything on the side of ZITADEL is done if the application is correctly create
## **AWS**: Test the connection
The result, you can now login to you AWS account through your ZITADEL-login with the AWS SSO Sign-in URL, which you
The result, you can now log in to you AWS account through your ZITADEL-login with the AWS SSO Sign-in URL, which you
should have saved in "Change to external identity provider ZITADEL" step 2.
apps/docs/content/guides/integrate/services/gitlab-self-hosted.mdx
+3 -3
View File
@@ -26,11 +26,11 @@ Follow [this guide](https://docs.gitlab.com/ee/administration/auth/oidc.html) of
Replace the values of the following fields:
- `args.client_options.identifier` with the `ClientId` generated by ZITADEL in the last step of [Create application in ZITADEL])()
- `args.client_options.secret` with the `ClientSecret` generated by ZITADEL in the last step of [Create application in ZITADEL])()
- `args.client_options.identifier` with the `ClientId` generated by ZITADEL
- `args.client_options.secret` with the `ClientSecret` generated by ZITADEL
- `args.client_options.redirect_uri` with the proper URL to your gitlab instance and callback
```yaml
```ruby
gitlab_rails['omniauth_providers'] = [
{
name: "openid_connect",
apps/docs/content/guides/integrate/services/pingidentity-saml.mdx
+1 -2
View File
@@ -23,8 +23,7 @@ Prerequisites:
## **Ping**: Create a new external identity provider
To add an
additional [external identity provider](https://docs.pingidentity.com/bundle/pingone/page/jvz1567784210191.html), you
To add an [external identity provider](https://docs.pingidentity.com/bundle/pingone/page/jvz1567784210191.html), you
can follow the instructions [here](https://docs.pingidentity.com/bundle/pingone/page/ovy1567784211297.html)
1. As described you have to create a new provider, with a unique identifier:
apps/docs/content/guides/integrate/tools/apache2.mdx
+3 -3
View File
@@ -6,7 +6,7 @@ This integration guide shows you the basic OpenID Connect integration with ZITAD
## Setup PKCE client in ZITADEL
- Go to your organization and setup a new application with the type PKCE
- Go to your organization and set up a new application with the type PKCE
- When created go to the "Redirect Settings" and *enable Development Mode*
- Add the Redirect Uri, f.e. `http://localhost:8080/secure/callback`
- Add the Post Logout Uri, f.e. `http://localhost:8080/index.html`
@@ -38,8 +38,8 @@ OIDCPKCEMethod S256
With the following parameters
| Parameter | Description | Example value|
|---|---|---|
| Parameter | Description | Example value |
|-------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------|
| OIDCProviderMetadataURL | Is the url to the discovery endpoint | `https://${CUSTOM_DOMAIN}/.well-known/openid-configuration` |
| OIDCClientID | Is the ID of the zitadel application. You can find it on the settings page of the application. | 123456789123@apache_test |
| OIDCRedirectURI | Users will be redirected to this page after successful login. If you are using localhost or any other non-https endpoint, make sure to enable development mode in ZITADEL. | https://mysecureapp.io/secure/callback |
apps/docs/content/guides/manage/cloud/start.mdx
+1 -1
View File
@@ -16,7 +16,7 @@ In a second step fill out your user data like First-, Last- and Team-name.
![](../../../../public/img/manuals/portal/customer_portal_landing_page_2.png)
If you did start with your email instead of a social login (e.g Google) you have to fill a password for your authentication.
If you did start with your email instead of a social login (e.g. Google) you have to fill a password for your authentication.
In that case you will get an initialization mail to verify your account.
![](../../../../public/img/manuals/portal/customer_portal_landing_page_3.png)
apps/docs/content/guides/manage/console/actions.mdx
+2 -2
View File
@@ -18,9 +18,9 @@ You can specify a timeout and whether the action is allowed to fail too.
<img src="/docs/img/guides/console/action.png" alt="Create Action" width="450px" />
To run those scripts, a flow with a trigger has to be created.
This could for example be a **External Authentication** Flow, with a **Post Authentication** trigger.
This could for example be an **External Authentication** Flow, with a **Post Authentication** trigger.
<img src="/docs/img/guides/console/flow.png" alt="Flow" width="400px" />
Now whenever a user gets authenticated externally with an IDP, a action is triggered after the authentication itself.
Now whenever a user gets authenticated externally with an IDP, an action is triggered after the authentication itself.
If you want to know more where actions can be useful, take a look at the feature [here](/concepts/features/actions) or directly jump to an example of a custom behavior [here](/guides/manage/customize/behavior).
apps/docs/content/guides/manage/console/administrators.mdx
+1 -1
View File
@@ -20,7 +20,7 @@ In the right part of the management console you can find **ADMINISTRATORS** in t
## Roles
| Name | Role | Description |
| ----------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------ |
|-------------------------------|-------------------------------|--------------------------------------------------------------------------------------------------------------|
| Instance Owner | IAM_OWNER | Manage the Instance, manage all organizations with their content |
| Instance Owner Viewer | IAM_OWNER_VIEWER | View the Instance and view all organizations with their content |
| Instance Org Manager | IAM_ORG_MANAGER | Manage all organizations including their policies, projects and users |
apps/docs/content/guides/manage/console/default-settings.mdx
+1 -1
View File
@@ -266,7 +266,7 @@ If an account is locked, the administrator has to unlock it in the ZITADEL Manag
### Add organization domain as suffix to loginnames
If you enable this setting, all loginnames will be suffixed with the organization domain. If this settings is disabled, you have to ensure that usernames are unique over all organizations.
If you enable this setting, all loginnames will be suffixed with the organization domain. If this setting is disabled, you have to ensure that usernames are unique over all organizations.
### Validate Org domains
apps/docs/content/guides/manage/console/overview.mdx
+1 -1
View File
@@ -21,7 +21,7 @@ Depending on your use case, multiple organizations can be created (B2B) or you c
width="400px"
/>
If your new to management console, you'll probably want to set some settings initially. Continue reading Default settings on the next page.
If you're new to management console, you'll probably want to set some settings initially. Continue reading Default settings on the next page.
## Prevent management console access
apps/docs/content/guides/manage/customize/behavior.mdx
+11 -11
View File
@@ -16,17 +16,17 @@ Before you start, make sure you have everything set up correctly.
## Copy some information for the action
1. Select the **Projects** navigation item.
1. Select a project that has a role configured.
1. Copy the projects **Resource Id** on the screens top right.
1. Scroll to the **ROLES** section and note some roles key.
2. Select a project that has a role configured.
3. Copy the projects **Resource ID** on the screens top right.
4. Scroll to the **ROLES** section and note some roles key.
## Create the action
1. Select the **Actions** navigation item.
1. In the **Actions <i className="las la-code"></i>** section, select the **+ New** button.
1. Give the new action the name `addGrant`.
1. Paste this snippet into the multiline textfield.
1. Replace the snippets placeholders and select **Save**.
2. In the **Actions <i className="las la-code"></i>** section, select the **+ New** button.
3. Give the new action the name `addGrant`.
4. Paste this snippet into the multiline text-field.
5. Replace the snippets placeholders and select **Save**.
```js reference
https://github.com/zitadel/actions/blob/main/examples/add_user_grant.js
@@ -37,10 +37,10 @@ https://github.com/zitadel/actions/blob/main/examples/add_user_grant.js
Now, make the action hook into the [external authentication flow](/apis/actions/external-authentication).
1. In the **Flows <i className="las la-exchange-alt"></i>** section, select the **+ New** button.
1. Select the **Flow Type** _External Authentication_.
1. Select the **Trigger Type** _Post Creation_.
1. In the **Actions** dropdown, check _addGrant_.
1. Select the **Save** button.
2. Select the **Flow Type** _External Authentication_.
3. Select the **Trigger Type** _Post Creation_.
4. In the **Actions** dropdown, check _addGrant_.
5. Select the **Save** button.
New users automatically are assigned a role now if they register by authenticating with an external identity provider.
apps/docs/content/guides/manage/customize/branding.mdx
+2 -2
View File
@@ -35,7 +35,7 @@ The best way is to upload a ttf file after a successful upload you will see it i
### Advanced Settings
In the advanced behavior you can choose if the loginname suffix (domain e.g [email protected]) should be shown in the loginname screen or not and if the “ZITADEL watermark” should be hidden.
In the advanced behavior you can choose if the loginname suffix (domain e.g. [email protected]) should be shown in the loginname screen or not and if the “ZITADEL watermark” should be hidden.
## Trigger the private labeling for the login
@@ -44,7 +44,7 @@ If you like to trigger your settings for your applications you have different po
### 1. Primary Domain Scope
Send a [reserved scope](/apis/openidoauth/scopes) with your [authorization request](../../integrate/login/oidc/login-users) to trigger your organization.
The primary domain scope will restrict the login to your organization, so only users of your own organization will be able to login.
The primary domain scope will restrict the login to your organization, so only users of your own organization will be able to log in.
You can use our [OpenID Authentication Request Playground](https://zitadel.com/playgrounds/oidc) to learn more about how to trigger an [organization's policies and branding](https://zitadel.com/playgrounds/oidc#organization-policies-and-branding).
apps/docs/content/guides/manage/customize/texts.mdx
+4 -4
View File
@@ -6,13 +6,13 @@ You are able to customize the texts used from ZITADEL. This is possibly on the i
## Message Texts
Sometimes the users will get an email or phone message from ZITADEL (e.g Password Reset Request).
Sometimes the users will get an email or phone message from ZITADEL (e.g. Password Reset Request).
ZITADEL already has some good standard texts, but maybe you would like to customize it for your organization.
Go to the message text policy on your organization and you will find the different kinds of messages that are sent from ZITADEL.
Go to the message text policy on your organization, and you will find the different kinds of messages that are sent from ZITADEL.
Choose the template and the language you like to edit.
You can now change all the texts from a message.
As soon as you click into a input field you will see some attribute chips below the field.
As soon as you click into an input field you will see some attribute chips below the field.
These are the parameters you can include on this specific message.
![](../../../../public/img/console_message_texts.png)
@@ -21,7 +21,7 @@ These are the parameters you can include on this specific message.
Like the message texts you are also able to change the texts on the login interface.
First choose the screen and the language you like to edit.
You will see the default texts in the input field and you can overwrite them by typing into the box.
You will see the default texts in the input field, and you can overwrite them by typing into the box.
![](../../../../public/img/console_login_texts.png)
apps/docs/content/guides/start/_local_instance.mdx
+1 -1
View File
@@ -1 +1 @@
If you choose to run a local instance have a look at our [deploy](/self-hosting/deploy/overview) section, where we show you different possibilities on how to run ZITADEL.
If you choose to run a local instance have a look at our [deploy-section](/self-hosting/deploy/overview), where we show you different possibilities on how to run ZITADEL.
apps/docs/content/legal/annex-support-services.mdx
+1 -1
View File
@@ -54,7 +54,7 @@ Recertification of a unit, to be covered under Support Services, is required for
* units that run a release that is older than 180 days from the products most recent stable release
* requests for support on products and services purchased or supported from non-authorized resellers
Recertification of a unit requires payment of a Recertification Fee which results in a checkup of the unit by ZITADEL. The unit will be inspected to asses its condition and eligibility for service coverage.
Recertification of a unit requires payment of a Recertification Fee which results in a checkup of the unit by ZITADEL. The unit will be inspected to assess its condition and eligibility for service coverage.
Please contact us for current fees.
apps/docs/content/legal/data-processing-agreement.mdx
+2 -2
View File
@@ -236,7 +236,7 @@ Any notices shall be delivered to a Party in accordance with the notice provisio
### List of Parties
| Data Exporter | Data Importer |
| :---- | :---- |
|:-------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------|
| Name: The Party identified as the Customer in the Agreement. | Name: The Party identified as Zitadel in the Agreement. |
| Address: As identified in the Agreement. | Address: As identified in the Agreement. |
| Contact Person's Name, position and contact details: As identified in the Agreement. | Contact Person's Name, position and contact details: As identified in the Agreement. |
@@ -246,7 +246,7 @@ Any notices shall be delivered to a Party in accordance with the notice provisio
### Description of processing / transfer
| | Description |
| :---- | :---- |
|:-----------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------|
| **Categories of data subjects:** | As described in the section "Processing of Personal Data" of the DPA |
| **Categories of personal data:** | As described in the section "Processing of Personal Data" of the DPA |
| **Sensitive data:** | None. |
apps/docs/content/legal/policies/brand-trademark-policy.mdx
+2 -2
View File
@@ -15,9 +15,9 @@ If you are unsure about the use of our logos, please contact [[email protected]]
ZITADEL's brand assets and trademarks are proprietary assets owned exclusively by us.
No third party may claim ownership over brand assets and trademarks or brands and trademarks that are confusingly similar. This extends to all trademarks in image, textform, combined image and text, visual, and audio.
No third party may claim ownership over brand assets and trademarks or brands and trademarks that are confusingly similar. This extends to all trademarks in image, text-form, combined image and text, visual, and audio.
You must not include our brands and trademarks in the name of your product or service wether commercial or non-commercial, this includes, but is not limited to, websites, blogs, informational, advertising, and personal home pages, applications.
You must not include our brands and trademarks in the name of your product or service whether commercial or non-commercial, this includes, but is not limited to, websites, blogs, informational, advertising, and personal home pages, applications.
## Spelling
apps/docs/content/legal/policies/feature-development-policy.mdx
+1 -1
View File
@@ -10,7 +10,7 @@ This policy clarifies how we handle requests for feature prioritization and deve
## Why to do we have this policy?
Shaping of the roadmap and prioritization of features is done by ZITADEL.
You are welcome to give feedback on the [roadmap](https://zitadel.com/roadmap) and we are happy to [accept upstream pull requests](https://github.com/zitadel/zitadel/CONTRIBUTE.md) for ZITADEL.
You are welcome to give feedback on the [roadmap](https://zitadel.com/roadmap), and we are happy to [accept upstream pull requests](https://github.com/zitadel/zitadel/CONTRIBUTE.md) for ZITADEL.
In case you can't contribute directly to the open source version of ZITADEL, but want to accelerate development, we may develop the feature on request, under the conditions laid out in this policy.
apps/docs/content/legal/service-description/cloud-service-description.mdx
+3 -3
View File
@@ -43,7 +43,7 @@ You can freely choose the infrastructure and location to host ZITADEL.
### Responsibilities
Your obligations while operating and using ZITADEL are detailed in our [terms of service](/legal/terms-of-service#your-obligations) given the provisions in our [acceptable use policy](/legal/policies/acceptable-use-policy).
When using ZITADEL Cloud, we may processing data on behalf according to the [data processing agreement](/legal/data-processing-agreement).
When using ZITADEL Cloud, we may process data on behalf according to the [data processing agreement](/legal/data-processing-agreement).
In a self-hosted setup, you will be responsible for the cost, operations, and availability of your infrastructure.
For DDoS, bot, and threat detection and protection we rely on external services in ZITADEL Cloud.
@@ -55,7 +55,7 @@ You should configure your own service providers for production use cases.
In a self-hosted setup, you will be responsible for SMTP / SMS services, domains and certificates.
| Responsibility | ZITADEL Cloud | Self-Hosted |
| --- | --- | --- |
|------------------------|---------------------------|-------------|
| Data / Information | Customer | Customer |
| User Access | Customer | Customer |
| SMTP Service | Customer (trial: ZITADEL) | Customer |
@@ -81,5 +81,5 @@ Our backup strategy executes daily full backups and differential backups on much
In a disaster recovery scenario, our goal is to guarantee a recovery point objective (RPO) of 1h, and a higher but similar recovery time objective (RTO).
Under normal operations, RPO and RTO goals are below 1 minute.
If you you have different requirements we provide you with a flexible approach to backup, restore, and transfer data (f.e. to a self-hosted setup) through our APIs.
If you have different requirements we provide you with a flexible approach to back up, restore, and transfer data (f.e. to a self-hosted setup) through our APIs.
Please consult the [migration guides](/guides/migrate/introduction) for more information.
apps/docs/content/legal/service-description/service-level-description.mdx
+13 -13
View File
@@ -32,7 +32,7 @@ Available means that Core Services of ZITADEL Cloud respond to Customer Requests
### Customer Requests
Customer Requests means a HTTP request made by a Customer or a Customers’ users to Core Services within the Customer’s organization’s region.
Customer Requests means an HTTP request made by a Customer or a Customers’ users to Core Services within the Customer’s organization’s region.
### Successful Minute
@@ -45,7 +45,7 @@ Failed Customer Request means Customer Requests that
This excludes specifically:
- Failed Customer Requests due to malformed requests, client-side application errors outside of ZITADEL Cloud’s control
- Failed Customer Requests due to malformed requests, client-side application errors outside ZITADEL Cloud’s control
- Customer Requests that do not reach ZITADEL Cloud Core Services
### Core Services
@@ -56,18 +56,18 @@ Core Services means the following ZITADEL Cloud Services and API’s:
- **OpenID Connect 1.0 / OAuth 2.0 API** Endpoints
- **SAML 2.0** Endpoints
- **Login Service** means the graphical user interface of ZITADEL Cloud for users to Login, Self-Register, and conduct a Password Reset.
- **Identity Brokering Service** means the component of ZITADEL Cloud that handles federated authentication of users with third-party identity provider, excluding any failure or misconfiguration by the third-party
- **Identity Brokering Service** means the component of ZITADEL Cloud that handles federated authentication of users with third-party identity provider, excluding any failure or misconfiguration by the third party
### Financial Credit
**Financial Credit** means the percent of the monthly subscription fee applicable to the month in which the guaranteed service level was not met, according to the actual achieved monthly uptime percentage, as shown in the following table
Achieved vs. Guaranteed| 99.50% | 99.90% | 99.95%
--- | --- | --- | ---
99.5% - < 99.9% | n/a | n/a | 10%
99.0% - < 99.5% | n/a | 10% | 25%
95.0% - < 99.0% | 10% | 25% | 50%
< 95.0% | 50% | 50% | 50%
| Achieved vs. Guaranteed | 99.50% | 99.90% | 99.95% |
|--------------------------|--------|--------|--------|
| 99.5% - < 99.9% | n/a | n/a | 10% |
| 99.0% - < 99.5% | n/a | 10% | 25% |
| 95.0% - < 99.0% | 10% | 25% | 50% |
| < 95.0% | 50% | 50% | 50% |
## Service Levels
@@ -75,10 +75,10 @@ Achieved vs. Guaranteed| 99.50% | 99.90% | 99.95%
1. During the term of the subscription agreement under which CAOS has agreed to provide ZITADEL Cloud to Customer, the Core Services will provide a Monthly Uptime Percentage to Customer conditional on the subscription plan as follows (the “SLO”):
Option | Monthly Uptime Percentage
--- | ---
Default | 99.50%
Extended SLA | 99.95%
| Option | Monthly Uptime Percentage |
|--------------|---------------------------|
| Default | 99.50% |
| Extended SLA | 99.95% |
1. If CAOS Ltd. does not meet the guaranteed service level, Customer might be eligible to receive Financial Credit as described in this document. Financial Credit shall be the sole and exclusive remedy for breach of this SLA.
2. The Customer must request Financial Credit and must notify CAOS Support in writing within 30 days of becoming eligible for Financial Credit and must prove Failed Customer Requests during Downtime Periods. Financial Credit will be made in the form of a monetary credit applied to the next possible subscription invoice of ZITADEL Cloud, may only be used to book services in the future, and will in no case be paid as a cash equivalent. No further guarantees are provided.
apps/docs/content/legal/subprocessors.mdx
+1 -1
View File
@@ -14,4 +14,4 @@ This explains the limited processing of customer data the entity is authorized t
We regularly audit all data processing agreements that we have with our sub-processors to guarantee that they adhere to the same level of privacy as ours to protect your personal data.
You can find [the full list of sub-processors in our trust center](https://trust.zitadel.com/subprocessors). We try to minimize the number of sub-processors that handle end-user data on our behalf to reduce any vendor related risks.
Some providers are used by default, but you can opt-out of the default provide and replace the sub-processor by a provider of your choice.
Some providers are used by default, but you can opt out of the default provider and replace the sub-processor by a provider of your choice.
apps/docs/content/sdk-examples/flutter.mdx
+1 -1
View File
@@ -40,7 +40,7 @@ This library is built by our community.
### Example Application
The [zitadel-flutter](https://github.com/zitadel/zitadel_flutter) repository includes an Example Application ready to start and show how an Flutter application looks like with integrated ZITADEL Login.
The [zitadel-flutter](https://github.com/zitadel/zitadel_flutter) repository includes an Example Application ready to start and show how a Flutter application looks like with integrated ZITADEL Login.
What does the Example include:
- Home Page with Login Button
apps/docs/content/sdk-examples/go.mdx
+3 -3
View File
@@ -75,7 +75,7 @@ What does the API Application Example include:
### Step-By-Step Guide
For Go we do have two different Step-By-Step Guides.
For Go, we do have two different Step-By-Step Guides.
One to create your web application with integrated login and one to create your API with permission checks for calling users.
The guides lead you through the whole process from configuring the right application in ZITADEL to a ready application with integrated login or authentication checks.
@@ -84,8 +84,8 @@ The guides lead you through the whole process from configuring the right applica
After completing the Step-By-Step Guide you will have:
1. Example Web Application with integrated ZITADEL Login
2. Example page accessible by authenticated user showing retrieved user information
4. Logout
5. Correct setup for your application in ZITADEL
3. Logout
4. Correct setup for your application in ZITADEL
[Web APP Step-By-Step Guide](/examples/login/go)
apps/docs/content/sdk-examples/introduction.mdx
+3 -3
View File
@@ -39,7 +39,7 @@ To begin configuring login for any of these samples, start [here](https://zitade
## OIDC Libraries
OIDC is a standard for authentication and most languages and frameworks do provide a OIDC library which can be easily integrated to your application.
If we do not provide an specific example, SDK or guide, we strongly recommend using existing authentication libraries for your
If we do not provide a specific example, SDK or guide, we strongly recommend using existing authentication libraries for your
language or framework instead of building your own.
Certified libraries have undergone rigorous testing and validation to ensure high security and reliability.
There are many recommended libraries available, this saves time and ensures that users' data is well-protected.
@@ -52,7 +52,7 @@ You might want to check out the following links to find a good library:
## Other example applications
- [B2B customer portal](https://github.com/zitadel/zitadel-nextjs-b2b): Showcase the use of personal access tokens in a B2B environment. Uses NextJS Framework.
- [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
- [Fine-grained authorization](https://github.com/zitadel/example-fine-grained-authorization): Leverage actions, custom metadata, and claims for attribute-based access control
@@ -72,7 +72,7 @@ the [buf plugin registry](https://buf.build/plugins) for more ideas.
### Example with Ruby
With gRPC we usually need to generate the client stub and the messages/types. This is why we need two plugins.
With gRPC, we usually need to generate the client stub and the messages/types. This is why we need two plugins.
The plugin `grpc/ruby` generates the client stub and the plugin `protocolbuffers/ruby` takes care of the messages/types.
```yaml
apps/docs/content/sdk-examples/nestjs.mdx
+1 -1
View File
@@ -21,7 +21,7 @@ This example uses **[@auth/core](https://www.npmjs.com/package/@auth/core)**, th
## What this example demonstrates
This example implements a complete authentication flow using [PKCE](https://oauth.net/2/pkce/) with [Zitadel](https://oauth.net/2/pkce/) with [Zitadel](https://zitadel.com/docs) as the identity provider. Users begin on a public landing page and click a login button to authenticate through Zitadel's authorization server. After successful authentication, they're redirected to a protected profile page displaying their user information retrieved from the [ID token](https://oauth.net/2/pkce/) with [Zitadel](https://zitadel.com/docs) as the identity provider. Users begin on a public landing page and click a login button to authenticate through Zitadel's authorization server. After successful authentication, they're redirected to a protected profile page displaying their user information retrieved from the [ID token](https://zitadel.com/docs/apis/openidoauth/claims) and [access token](https://zitadel.com/docs/apis/openidoauth/endpoints#token_endpoint).
This example implements a complete authentication flow using [PKCE](https://oauth.net/2/pkce/) with [Zitadel](https://zitadel.com/docs) as the identity provider. Users begin on a public landing page and click a login button to authenticate through Zitadel's authorization server. After successful authentication, they're redirected to a protected profile page displaying their user information retrieved from the [ID token](https://oauth.net/2/pkce/) with [Zitadel](https://zitadel.com/docs) as the identity provider. Users begin on a public landing page and click a login button to authenticate through Zitadel's authorization server. After successful authentication, they're redirected to a protected profile page displaying their user information retrieved from the [ID token](https://zitadel.com/docs/apis/openidoauth/claims) and [access token](https://zitadel.com/docs/apis/openidoauth/endpoints#token_endpoint).
The application leverages [NestJS controllers](https://docs.nestjs.com/controllers) to handle authentication routes and [@mridang/nestjs-auth guards](https://docs.nestjs.com/controllers) to handle authentication routes and [@mridang/nestjs-auth guards](https://www.npmjs.com/package/@mridang/nestjs-auth) to protect routes requiring authentication. [Session management](https://docs.nestjs.com/controllers) to handle authentication routes and [@mridang/nestjs-auth guards](https://www.npmjs.com/package/@mridang/nestjs-auth) to protect routes requiring authentication. [Session management](https://zitadel.com/docs/guides/integrate/login/oidc/login-users) is handled through encrypted [JWT-based sessions](https://docs.nestjs.com/controllers) to handle authentication routes and [@mridang/nestjs-auth guards](https://www.npmjs.com/package/@mridang/nestjs-auth) to protect routes requiring authentication. [Session management](https://zitadel.com/docs/guides/integrate/login/oidc/login-users) is handled through encrypted [JWT-based sessions](https://authjs.dev/concepts/session-strategies#jwt-session) stored in secure, HTTP-only cookies. The example includes automatic [token refresh](https://docs.nestjs.com/controllers) to handle authentication routes and [@mridang/nestjs-auth guards](https://www.npmjs.com/package/@mridang/nestjs-auth) to protect routes requiring authentication. [Session management](https://zitadel.com/docs/guides/integrate/login/oidc/login-users) is handled through encrypted [JWT-based sessions](https://authjs.dev/concepts/session-strategies#jwt-session) stored in secure, HTTP-only cookies. The example includes automatic [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) functionality using [refresh tokens](https://oauth.net/2/pkce/), ensuring users maintain their sessions without interruption when access tokens expire.
apps/docs/content/self-hosting/deploy/kubernetes/configuration.mdx
+1 -1
View File
@@ -81,7 +81,7 @@ zitadel:
```
| Setting | Description |
|---------|-------------|
|------------------|----------------------------------------------|
| `ExternalDomain` | The public domain name (no protocol or port) |
| `ExternalPort` | The public port (443 for HTTPS, 80 for HTTP) |
| `ExternalSecure` | Whether the external connection uses HTTPS |
apps/docs/content/self-hosting/deploy/overview.mdx
+1 -1
View File
@@ -13,7 +13,7 @@ Choose your platform and run ZITADEL with the most minimal configuration possibl
## Prerequisites
- For test environments, ZITADEL does not need many resources, 1 CPU and 512MB memory are more than enough. (With more CPU, the password hashing might be faster)
- A PostgreSQL as only needed storage. Make sure to read our [Production Guide](/self-hosting/manage/production#prefer-postgre-sql) before you decide to use Postgresql.
- A PostgreSQL as only needed storage. Make sure to read our [Production Guide](/self-hosting/manage/production#prefer-postgre-sql) before you decide to use PostgreSQL.
## Releases
apps/docs/content/self-hosting/deploy/troubleshooting/_instance_not_found.mdx
+1 -1
View File
@@ -1,5 +1,5 @@
`ID=QUERY-n0wng Message=Instance not found`
If you're self hosting with a Custom Domain, you need to instruct ZITADEL to use the `ExternalDomain`.
If you're self-hosting with a Custom Domain, you need to instruct ZITADEL to use the `ExternalDomain`.
You can find further instructions in our guide about [Custom Domains](/self-hosting/manage/custom-domain).
We also provide a guide on how to [configure](/self-hosting/manage/configure) ZITADEL with variables from files or environment variables.
apps/docs/content/self-hosting/manage/custom-domain.mdx
+2 -2
View File
@@ -47,7 +47,7 @@ Check out the [reverse proxy configuration examples](/self-hosting/manage/revers
## Organization Domains
Note that by default, you cannot access ZITADEL at an organizations domain.
Note that by default, you cannot access ZITADEL at an organization's domain.
Organization level domains [are intended for routing users by their login methods to their correct organization](/guides/solution-scenarios/domain-discovery).
However, if you want to access ZITADEL at an organization domain, [you can add additional domains using the System API](/reference/api/system/zitadel.system.v1.SystemService.AddDomain).
@@ -60,5 +60,5 @@ You can immediately access the ZITADEL Management Console and APIs using these s
## More Information
- [Check out the production-near loadbalancing example with Traefik](/self-hosting/manage/reverseproxy/traefik)
- [Check out the production-near load-balancing example with Traefik](/self-hosting/manage/reverseproxy/traefik)
- [Explore some concrete proxy configuration examples for ZITADEL using the domain 127.0.0.1.sslip.io](/self-hosting/manage/reverseproxy/reverse_proxy)
apps/docs/content/self-hosting/manage/productionchecklist.mdx
+2 -2
View File
@@ -25,7 +25,7 @@ To apply best practices to your production setup we created a step by step check
- [ ] Test the restore scenarios before going live
- [ ] Secure database connections from outside your network and/or use an internal subnet for database connectivity
- [ ] High Availability for critical infrastructure components (depending on your setup)
- [ ] Loadbalancer
- [ ] Load-balancer
- [ ] [Reverse Proxies](/self-hosting/manage/reverseproxy/reverse_proxy)
- [ ] Web Application Firewall
@@ -55,7 +55,7 @@ To apply best practices to your production setup we created a step by step check
### Monitoring
Use an appropriate monitoring solution to have an overview about your ZITADEL instance. In particular you may want to watch out for things like:
Use an appropriate monitoring solution to have an overview about your ZITADEL instance. In particular, you may want to watch out for things like:
- [ ] CPU and memory of ZITADEL and the database
- [ ] Open database connections
apps/docs/content/self-hosting/manage/reverseproxy/cloudflare/index.mdx
+2 -2
View File
@@ -7,7 +7,7 @@ sidebar_label: Cloudflare
- [Make sure HTTP/2 is enabled](https://support.cloudflare.com/hc/en-us/articles/200168076-Understanding-Cloudflare-HTTP-2-and-HTTP-3-Support)
- [Verify that gRPC is enabled](https://support.cloudflare.com/hc/en-us/articles/360050483011-Understanding-Cloudflare-gRPC-support)
- [Verify that traffic is proxied through cloudflare](https://developers.cloudflare.com/dns/manage-dns-records/reference/proxied-dns-records/)
- [Verify that traffic is proxied through Cloudflare](https://developers.cloudflare.com/dns/manage-dns-records/reference/proxied-dns-records/)
- [Configure Zitadel to use the TLS Mode enabled](/self-hosting/manage/tls_modes#enabled)
<Callout>
@@ -16,7 +16,7 @@ sidebar_label: Cloudflare
## Troubleshooting
If something is not working please check the cloudflare WAF rules for potential violations.
If something is not working please check the Cloudflare WAF rules for potential violations.
These two rules are known to be triggered:
- 100001 Anomaly:Header:User-Agent - Missing Cloudflare Specials
apps/docs/content/self-hosting/manage/reverseproxy/zitadel_cloud/index.mdx
+3 -3
View File
@@ -5,12 +5,12 @@ sidebar_label: Fronting Zitadel Cloud
## Fronting Zitadel Cloud
You can use your reverseproxy, content delivery network (CDN) or web application firewall (WAF) to front Zitadel Cloud.
However we currently do not recommend this for production settings.
You can use your reverse-proxy, content delivery network (CDN) or web application firewall (WAF) to front Zitadel Cloud.
However, we currently do not recommend this for production settings.
To configure your service that fronts Zitadel please have a look at the vendors in this page.
## Things to look out for when fronting Zitadel Cloud
- Cache-control - Zitadel Cloud uses a CDN to globally distribute data. Please try to avoid overriding this header as it may lead to sideeffects
- Cache-control - Zitadel Cloud uses a CDN to globally distribute data. Please try to avoid overriding this header as it may lead to side-effects
- Rate Limits - Zitadel Cloud uses a combination of static and dynamic rate limits. If you receive occasional 429 headers you are rate limited.
apps/docs/content/support/advisory/a10001.mdx
+1 -1
View File
@@ -16,7 +16,7 @@ If you on the other hand want users to be able to federate their accounts from a
Further ZITADEL provided the possibility to disable registration on each IDP with the introduction of IDP Templates.
To address this, we are going to change the behavior of the setting mentioned above, so that if disable, it will only prevent local registration. Registration of a federated user will still be possible - if not disabled by the corresponding IDP Template.
To address this, we are going to change the behavior of the setting mentioned above, so that if disabled, it will only prevent local registration. Registration of a federated user will still be possible - if not disabled by the corresponding IDP Template.
## Statement
apps/docs/content/support/advisory/a10004.mdx
+2 -2
View File
@@ -14,7 +14,7 @@ Due to storage optimizations ZITADEL changes the behavior of sequences.
This change improves command (create, update, delete) performance of ZITADEL.
Sequences are no longer unique inside an instance.
From now on sequences are upcounting per aggregate id.
From now on sequences are counting up per aggregate id.
For example sequences of newly created users begin at 1.
Existing sequences remain untouched.
@@ -27,7 +27,7 @@ As soon as the release version is published, we will include the version here.
If you use the ListEvents API to scrape events use the creation date instead of the sequence.
If you use sequences on a list of objects it's no longer guaranteed to have unique sequences across the list.
Therefore it's recommended to use the change data of the objects instead.
Therefore, it's recommended to use the change data of the objects instead.
## Impact
apps/docs/content/support/advisory/a10006.mdx
+2 -2
View File
@@ -12,7 +12,7 @@ Date: Calendar week 41/42 2023
Versions >= 2.39.0 require the cockroach database user of ZITADEL to be granted to the `VIEWACTIVITY` grant. This can either be reached by grant the role manually or execute the `zitadel init` command.
Cockroach versions 22.2 < 22.2.11 and 23.1 < 23.1.4 will fail the migration. Please make sure to upgrade to more recent versions first. ZITADEL recommends to use the latest stable version of Cockroachdb.
Cockroach versions 22.2 < 22.2.11 and 23.1 < 23.1.4 will fail the migration. Please make sure to upgrade to more recent versions first. ZITADEL recommends to use the latest stable version of CockroachDB.
## Statement
@@ -22,7 +22,7 @@ To query correct order of events the cockroach database user of ZITADEL needs ad
Before migrating to versions >= 2.39.0 make sure the cockroach database user has sufficient grants.
Cockroachdb version is up to date.
CockroachDB version is up to date.
## Impact
apps/docs/content/support/advisory/a10007.mdx
+1 -1
View File
@@ -15,7 +15,7 @@ This advisory applies to self-hosted ZITADEL installations with custom roles to
## Description
In upcoming ZITADEL versions, RBAC also applies to [system users defined in the ZITADEL runtime configuration](/guides/integrate/zitadel-apis/access-zitadel-system-api#runtime-configuration).
This enables fine grained access control to the system API as well as other APIs for system users.
This enables fine-grained access control to the system API as well as other APIs for system users.
ZITADEL defines the new default roles *SYSTEM_OWNER* and *SYSTEM_OWNER_VIEWER*.
System users without any memberships defined in the configuration will be assigned the *SYSTEM_OWNER* role.
**Self-hosting users who define their own custom mapping at the *InternalAuthZ.RolePermissionMappings* configuration section**, have to define the *SYSTEM_OWNER* role in their configuration too to be able to access the system API with the default system user membership.
apps/docs/content/support/advisory/a10009.mdx
+3 -3
View File
@@ -10,17 +10,17 @@ Date: 2024-05-28
## Description
There were rare cases where Cockroachdb got blocked during runtime of ZITADEL and returned `WRITE_TOO_OLD`-errors to ZITADEL. The root cause of the problem is described in [this github issue of the database](https://github.com/cockroachdb/cockroach/issues/77119). The workaround provided by the database is enabling the `enable_durable_locking_for_serializable`-flag as described [here](https://github.com/cockroachdb/cockroach/issues/75456#issuecomment-1936277716).
There were rare cases where CockroachDB got blocked during runtime of ZITADEL and returned `WRITE_TOO_OLD`-errors to ZITADEL. The root cause of the problem is described in [this GitHub issue of the database](https://github.com/cockroachdb/cockroach/issues/77119). The workaround provided by the database is enabling the `enable_durable_locking_for_serializable`-flag as described [here](https://github.com/cockroachdb/cockroach/issues/75456#issuecomment-1936277716).
Because enabling flags requires admin privileges the statement must be executed manually or by executing `zitadel init` command.
## Statement
Ensure lock distribution for `FOR UPDATE`-statements on Cockroachdb.
Ensure lock distribution for `FOR UPDATE`-statements on CockroachDB.
## Mitigation
Cockroachdb version >= 23.2.
CockroachDB version >= 23.2.
## Impact
apps/docs/content/support/advisory/a10012.mdx
+4 -4
View File
@@ -17,13 +17,13 @@ they are reduced into projections in bulk batches. Projections allow for efficie
We've investigated multiple reports of outdated projections.
For example created users missing in get requests, or missing data after a ZITADEL upgrade[^1].
The conclusion is that the transaction in which we perform a bulk of queries can timeout.
The conclusion is that the transaction in which we perform a bulk of queries can time out.
The old setting defined a transaction duration of 500ms for a bulk of 200 events.
A single event may create multiple statements in a single projection.
A timeout may occur even if the actual bulk size is less than 200,
which then results in more back-pressure on a busy system, leading to more timeouts and effectively dead-locking a projection.
which then results in more back-pressure on a busy system, leading to more timeouts and effectively deadlocking a projection.
Increasing or disabling the projection transaction duration solved dead-locks in all reported cases.
Increasing or disabling the projection transaction duration solved deadlocks in all reported cases.
We've decided to increase the transaction duration to 1 minute.
Due to the high value it is functionally similar to disabling,
however it still provides a safety net for transaction that do freeze,
@@ -39,7 +39,7 @@ This change was submitted in the following PR:
## Mitigation
If you have a custom configuration for projections, this update will not apply to your system or some projections. When encountering projection dead-lock consider increasing the timeout to the new default value.
If you have a custom configuration for projections, this update will not apply to your system or some projections. When encountering projection deadlock consider increasing the timeout to the new default value.
Note that entries under `Customizations` overwrite the global settings for a single projection.
apps/docs/content/support/advisory/a10016.mdx
+2 -2
View File
@@ -21,7 +21,7 @@ Last updated: 2025-05-19
### Background
Zitadel uses a eventstore table as main source of truth for state changes.
Zitadel uses an eventstore table as main source of truth for state changes.
Projections are tables which provide alternative views of state, which are built using events.
In order to know which events are reduced into projections, we use a `position` column in the eventstore and a dedicated table which records the current state.
@@ -31,7 +31,7 @@ Zitadel prior to the listed version had a precision bug. The `position` column u
## Impact
During a past attempt to fix this, we got reports of failing projections inside Zitadel. Because the precision became exact certain compare operations like *equal*, *less then*, etc would now return different results. This was because the values in `current_states` would already have lost precision from a broken version. This might happen to **some** deployments or projections: there is only a small probability.
During a past attempt to fix this, we got reports of failing projections inside Zitadel. Because the precision became exact certain compare operations like *equal*, *less than*, etc. would now return different results. This was because the values in `current_states` would already have lost precision from a broken version. This might happen to **some** deployments or projections: there is only a small probability.
We are releasing the fix again and your system might get affected.
apps/docs/content/support/technical_advisory.mdx
+5 -5
View File
@@ -6,7 +6,7 @@ sidebar_label: Technical Advisories
Technical advisories are notices that report major issues with ZITADEL Self-Hosted or the ZITADEL Cloud platform that could potentially impact security or stability in production environments.
These advisories may include details about the nature of the issue, its potential impact, and recommended mitigation actions.
Users are strongly encouraged to evaluate these advisories and consider the recommended mitigation actions independently from their version upgrade schedule.
Users are strongly encouraged to evaluate these advisories and consider the recommended mitigation actions independently of their version upgrade schedule.
We understand that these advisories may include breaking changes, and we aim to provide clear guidance on how to address these changes.
<table>
@@ -64,7 +64,7 @@ We understand that these advisories may include breaking changes, and we aim to
keep the library up-to-date, the management console UI will loose its dynamic theming
capability. If you need users to have your branding settings (background-,
button-, link and text coloring) you should implement your own user
facing UI yourself and not use ZITADELs management console UI.
facing UI yourself and not use ZITADEL's management console UI.
ZITADEL hosted Login-UI is not affected by this change.
</td>
<td>2.40.0</td>
@@ -96,7 +96,7 @@ We understand that these advisories may include breaking changes, and we aim to
Due to storage optimizations ZITADEL changes the behavior of sequences.
This change improves command (create, update, delete) performance of ZITADEL.
Sequences are no longer unique inside an instance.
From now on sequences are upcounting per aggregate id.
From now on sequences are incrementing per aggregate id.
For example sequences of newly created users begin at 1.
Existing sequences remain untouched.
</td>
@@ -113,7 +113,7 @@ We understand that these advisories may include breaking changes, and we aim to
Migrating to versions &gt;= 2.39 from &lt; 2.39 will cause down time during setup starts and the new version is started.
This is caused by storage optimizations which replace the `eventstore.events` database table with the new `eventstore.events2` table.
All existing events are migrated during the execution of the `zitadel setup` command.
New events will be inserted into the new `eventstore.events2` table. The old table `evetstore.events` is renamed to `eventstore.events_old` and will be dropped in a future release of ZITADEL.
New events will be inserted into the new `eventstore.events2` table. The old table `eventstore.events` is renamed to `eventstore.events_old` and will be dropped in a future release of ZITADEL.
</td>
<td>2.39.0</td>
<td>Calendar week 41/42 2023</td>
@@ -256,7 +256,7 @@ We understand that these advisories may include breaking changes, and we aim to
If you want to stay up to date on our technical advisories, we recommend subscribing to our [Technical Advisory mailing list](https://share-eu1.hsforms.com/1NAOUyAMmRzSnB7uP665xHA2dljbt) or visiting our [website](https://zitadel.com/technical-advisory).
As ZITADEL Cloud customer, you can also login to the <a href="https://zitadel.com/admin">ZITADEL Customer Portal</a> and enable the Technical Advisory <a href="https://zitadel.com/admin/settings">Notifications</a> in your settings.
As ZITADEL Cloud customer, you can also log in to the <a href="https://zitadel.com/admin">ZITADEL Customer Portal</a> and enable the Technical Advisory <a href="https://zitadel.com/admin/settings">Notifications</a> in your settings.
## Categories
apps/docs/content/support/troubleshooting.mdx
+7 -7
View File
@@ -21,7 +21,7 @@ Also check if "block all cookies" is active. If so please disable this setting.
To make sure, that your new settings will trigger, please restart your mobile phone and try it again.
**Settings > Safari > Advanced > Experimental Features > disable: „SameSite strict enforcement (ITP)“**
**Settings > Safari > Advanced > Experimental Features > disable: "SameSite strict enforcement (ITP)"**
![Same Site Strict Enforcement](../../public/img/manuals/errors/same-site-strict.png)
@@ -50,7 +50,7 @@ End-users authenticate to an application in your frontend project.
The frontend then sends requests to the backend, validates the token with ZITADEL's introspection endpoint, and returns a payload to the frontend.
The backend returns the error `invalid audience (APP-Zxfako)`.
You must add the scope `urn:zitadel:iam:org:project:id:{projectId}:aud` to the auth request that is send from the front end.
You must add the scope `urn:zitadel:iam:org:project:id:{projectId}:aud` to the auth request that is sent from the front end.
Replace `projectId` with the projectId of your backend.
### Accessing ZITADEL's APIs
@@ -59,7 +59,7 @@ You have a project for a frontend application.
The application should also access the API of your ZITADEL, for example to pull a list of all users and display them on a user page.
End-users authenticate to the application in the frontend project, but when calling the management API you get the error `invalid audience (APP-Zxfako)`.
You must add the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to the auth request that is send from the front end.
You must add the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to the auth request that is sent from the front end.
When accessing your ZITADEL instance's APIs they act as a resource server.
You can check the Management Console or via API and see that when you open your default organization there exists a project "ZITADEL" that contains different applications for each API and the Console.
@@ -68,11 +68,11 @@ Instead of `urn:zitadel:iam:org:project:id:zitadel:aud` you could also use `urn:
## WebFinger requirement for Tailscale
The WebFinger requirement and setup is a step a user has to take outside of their IdP set-up. WebFinger is a protocol which supports the ability for OIDC issuer discovery, and we use it to prove that the user has administrative control over the domain and to retrieve the issuer. This is a requirement we have in place for all users, regardless of their IdP, who use custom OIDC with Tailscale.
The WebFinger requirement and setup is a step a user has to take outside their IdP set-up. WebFinger is a protocol which supports the ability for OIDC issuer discovery, and we use it to prove that the user has administrative control over the domain and to retrieve the issuer. This is a requirement we have in place for all users, regardless of their IdP, who use custom OIDC with Tailscale.
On their Custom Domain, e.g example.com, users need to host a WebFinger endpoint at https://example.com/.well-known/webfinger. When queried, this endpoint returns a JSON response detailing the issuer. Users would need to host the endpoint with the link to the ZITADEL issuer. Tailscale only looks up this endpoint once when a user signs up, and will only look up this endpoint again if the user needs to make a configuration change to their identity provider.
On their Custom Domain, e.g. example.com, users need to host a WebFinger endpoint at https://example.com/.well-known/webfinger. When queried, this endpoint returns a JSON response detailing the issuer. Users would need to host the endpoint with the link to the ZITADEL issuer. Tailscale only looks up this endpoint once when a user signs up, and will only look up this endpoint again if the user needs to make a configuration change to their identity provider.
The requirements and a set up guide is detailed in the [Tailscale documentation](https://tailscale.com/kb/1240/sso-custom-oidc/).
The requirements and a set-up guide is detailed in the [Tailscale documentation](https://tailscale.com/kb/1240/sso-custom-oidc/).
## Login not possible. The organization of the user must be granted to the project
@@ -103,7 +103,7 @@ You do have two possibilities.
1. Go to the organization, who owns the project, where the user tries to authenticate.
2. Navigate to the Project Grants page of the needed project
3. Click on the "New" button
4. Search for the organization to which you want to grant the project (e.g Organization B)
4. Search for the organization to which you want to grant the project (e.g. Organization B)
5. Select the roles you want to grant
6. Click save

Some files were not shown because too many files have changed in this diff Show More