andwati/zitadel
1
0
Fork 0
mirror of https://github.com/andwati/zitadel.git synced 2026-11-08 07:05:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: naming inconsistency application (#11431)

Browse Source
This commit is contained in:
Wim Van Laer
2026-02-04 07:20:07 +00:00
committed by GitHub
parent 04c58c5b3f
commit 61d4060df3
96 changed files with 22550 additions and 22674 deletions
Download Patch File Download Diff File Expand all files Collapse all files
apps/docs/content/apis/benchmarks/index.mdx
+1 -1
View File
@@ -104,4 +104,4 @@ Will be established as soon as the goal described above is reached.
This chapter provides a table linking to the detailed test results.
<DocCardList />
<DocCardList/>
apps/docs/content/apis/introduction.mdx
+1 -1
View File
@@ -111,7 +111,7 @@ API Reference:
### Management
The management API is as the name states the interface where systems can mutate IAM objects like, organizations, projects, clients, users and so on if they have the necessary access rights.
The management API is as the name states the interface where systems can mutate IAM objects like, organizations, projects, applications, users and so on if they have the necessary access rights.
To identify the current organization you can send a header `x-zitadel-orgid` or if no header is set, the organization of the authenticated user is set.
</div>
apps/docs/content/apis/migration_v1_to_v2.mdx
+3 -3
View File
@@ -49,7 +49,7 @@ This section details the migrated resources, including any breaking changes and
### General Changes
#### Sunsetting OpenAPI/REST Support in Favor of Connect RPC
While our v1 API already offered gRPC, it also provided a parallel REST/OpenAPI interface for clients who preferred making traditional HTTP calls.
While our v1 API already offered gRPC, it also provided a parallel REST/OpenAPI interface for applications who preferred making traditional HTTP calls.
In our v2 API, we are consolidating our efforts to provide a more streamlined and efficient development experience.
The primary change is the removal of the OpenAPI/REST interface.
@@ -62,10 +62,10 @@ 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.
- Connect RPC: For making CRUD-like (Create, Read, Update, Delete) calls over HTTP. This is the recommended path for most clients migrating from our v1 REST API.
- 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.
Based on our .proto service definitions, you can generate type-safe clients for your specific programming language, whether you use native gRPC or Connect RPC.
Based on our .proto service definitions, you can generate type-safe applications for your specific programming language, whether you use native gRPC or Connect RPC.
This eliminates the need to write boilerplate code for handling HTTP requests and parsing responses, leading to a more streamlined and less error-prone development process.
#### Contextual Information in the Request Body
apps/docs/content/apis/openidoauth/claims.mdx
+6 -6
View File
@@ -3,7 +3,7 @@ title: Claims in ZITADEL
sidebar_label: Claims
---
ZITADEL asserts claims on different places according to the corresponding specifications or project and clients settings.
ZITADEL asserts claims on different places according to the corresponding specifications or project and applications settings.
Please check below the matrix for an overview where which scope is asserted.
| Claims | Userinfo | Introspection | ID Token | Access Token |
@@ -63,7 +63,7 @@ Please check below the matrix for an overview where which scope is asserted.
| given_name | `Road` | First name of the subject |
| given_name | `Road` | First name of the subject |
| iat | `1311280970` | Time of the token was issued at (as unix time) |
| iss | `${CUSTOM_DOMAIN}` | Issuing domain of a token |
| iss | `${CUSTOM_DOMAIN}` | Issuing domain of a token |
| jti | `69234237813329048` | Unique id of the token |
| locale | `en` | Language from the subject |
| name | `Road Runner` | The subjects full name |
@@ -110,9 +110,9 @@ ZITADEL reserves some claims to assert certain data. Please check out the [reser
|:--------------------------------------------------|:---------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 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 client 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). |
| urn:zitadel:iam:org:project:\{projectid}:roles | `{"urn:zitadel:iam:org:project:id3:roles": [ {"user": {"id1": "acme.zitade.ch", "id2": "caos.ch"} } ] }` | When roles are asserted, ZITADEL does this by providing the `id` and `primaryDomain` below the role. This gives you the option to check in which organization a user has the role on a specific project. |
| urn:zitadel:iam:user:metadata | `{"urn:zitadel:iam:user:metadata": [ {"key": "VmFsdWU=" } ] }` | The metadata claim will include all metadata of a user. The values are base64 encoded. |
| urn:zitadel:iam:user:resourceowner:id | `{"urn:zitadel:iam:user:resourceowner:id": "orgid"}` | This claim represents the user's organization ID. |
| urn:zitadel:iam:user:resourceowner:name | `{"urn:zitadel:iam:user:resourceowner:name": "ACME"}` | This claim represents the user's organization's name. |
| urn:zitadel:iam:user:resourceowner:primary_domain | `{"urn:zitadel:iam:user:resourceowner:primary_domain": "acme.ch"}` | This claim represents the user's organization's primary domain. |
| urn:zitadel:iam:user:resourceowner:id | `{"urn:zitadel:iam:user:resourceowner:id": "orgid"}` | This claim represents the user's organization ID. |
| urn:zitadel:iam:user:resourceowner:name | `{"urn:zitadel:iam:user:resourceowner:name": "ACME"}` | This claim represents the user's organization's name. |
| urn:zitadel:iam:user:resourceowner:primary_domain | `{"urn:zitadel:iam:user:resourceowner:primary_domain": "acme.ch"}` | This claim represents the user's organization's primary domain. |
apps/docs/content/apis/openidoauth/endpoints.mdx
+10 -4
View File
@@ -44,7 +44,7 @@ authenticate the user in exchange for an authorization_code (authorization code
### Required request parameters
| Parameter | Description |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------|
| client_id | The id of your client as shown in Console. |
| redirect_uri | Callback uri of the authorization request where the code or tokens will be sent to. Must match exactly one of the preregistered in Console. |
| response_type | Determines whether a `code`, `id_token token` or just `id_token` will be returned. Most use cases will need `code`. See flow guide for more info. |
@@ -94,7 +94,7 @@ no additional parameters required
### Additional parameters
| Parameter | Description |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|---------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id_token_hint | Valid `id_token` (of an existing session) used to identity the subject. **SHOULD** be provided when using prompt `none`. |
| login_hint | A valid logon name of a user. Will be used for username inputs or preselecting a user on `select_account`. Be sure to encode the hint correctly using url encoding (especially when using `+` or alike in the loginname) |
| max_age | Seconds since the last active successful authentication of the user |
@@ -124,7 +124,7 @@ As per [OpenID Connect Core 1.0, Section 3.1.2.1](https://openid.net/specs/openi
When your `response_type` was `code` and no error occurred, the following response will be returned:
| Property | Description |
| -------- | ----------------------------------------------------------------------------- |
|----------|-------------------------------------------------------------------------------|
| code | Opaque string which will be necessary to request tokens on the token endpoint |
| state | Unmodified `state` parameter from the request |
@@ -133,7 +133,7 @@ When your `response_type` was `code` and no error occurred, the following respon
When your `response_type` was either `id_token` or `id_token token` and no error occurred, the following response will be returned:
| Property | Description |
| ------------ | ------------------------------------------------------------------------------------- |
|--------------|---------------------------------------------------------------------------------------|
| access_token | Only returned if `response_type` included `token` |
| expires_in | Number of second until the expiration of the `access_token` |
| id_token | An `id_token` of the authorized user |
@@ -265,6 +265,7 @@ curl --request POST \
```
#### Successful JWT profile response
| Property | Description |
| ------------ | ------------------------------------------------------------------------------------- |
| access_token | An `access_token` as JWT or opaque token |
@@ -331,6 +332,7 @@ Send a `client_assertion` as JWT for us to validate the signature against the re
</Tabs>
#### Successful refresh token response
| Property | Description |
| ------------- | ------------------------------------------------------------------------------------- |
| access_token | An `access_token` as JWT or opaque token |
@@ -379,6 +381,7 @@ curl --request POST \
```
#### Successful client credentials response
| Property | Description |
| ------------ | ------------------------------------------------------------------------------------- |
| access_token | An `access_token` as JWT or opaque token |
@@ -440,6 +443,7 @@ Send a `client_assertion` as JWT for us to validate the signature against the re
</Tabs>
#### Successful token exchange response
<TokenExchangeResponse components={props.components} />
#### Token types
@@ -537,6 +541,7 @@ Additionally and depending on the granted scopes, information about the authoriz
Check the [Claims](./claims) page if a specific claims might be returned and for detailed description.
### Error response
If the authorization fails, an HTTP 401 with `invalid_client` will be returned.
## userinfo_endpoint
@@ -554,6 +559,7 @@ curl --request GET \
```
### Successful userinfo response
If the `access_token` is valid, the information about the user depending on the granted scopes is returned.
Check the [Claims](./claims) page if a specific claims might be returned and for detailed description.
apps/docs/content/apis/statuscodes.mdx
+14 -14
View File
@@ -3,17 +3,17 @@ title: GRPC Status Codes in ZITADEL
sidebar_label: GRPC Status Codes
---
| GRPC Number | GRPC Code | HTTP Status Code | HTTP Status Text |Description |
| :---------| :------------------- | ------------------ | ------------- | -------------------------------------------------------------------------------------------------------------------------- |
| 0 | OK | 200 |OK | Not an error; returned on success. |
| 2 | UNKNOWN | 500 |Internal | Unknown error, this is sent if the error could not be identified as one of the errors described below |
| 3 | INVALID_ARGUMENT | 400 |Bad Request | The client specified an invalid argument. Note that this differs from FAILED_PRECONDITION. INVALID_ARGUMENT indicates arguments that are problematic regardless of the state of the system (e.g., a malformed file name). |
| 4 | DEADLINE_EXCEEDED | 504 |Gateway Timeout | The deadline expired before the operation could complete. |
| 5 | NOT_FOUND | 404 |Not found | Some requested entity (e.g. user or project) was not found. |
| 6 | ALREADY_EXISTS | 409 |Conflict | The entity that a client attempted to create (e.g. user or project) already exists. |
| 7 | PERMISSION_DENIED | 403 |Forbidden |The caller does not have permission to execute the specified operation. |
| 9 | FAILED_PRECONDITION | 400 |Bad Request | The operation was rejected because the system is not in a state required for the operation's execution. e.g a project that is already deactivated, should be deactivated |
| 12 | UNIMPLEMENTED | 501 |Not Implemented |The operation is not implemented or is not supported/enabled in this service. |
| 13 | INTERNAL | 500 |Internal |Internal errors. This means that some invariants expected by the underlying system have been broken. This error code is reserved for serious errors. |
| 14 | UNAVAILABLE | 503 |Service Unavailable | The service is currently unavailable. |
| 16 | UNAUTHENTICATED | 401 |Unauthorized |The request does not have valid authentication credentials for the operation. |
| GRPC Number | GRPC Code | HTTP Status Code | HTTP Status Text | Description |
|:------------|:--------------------|------------------|---------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 0 | OK | 200 | OK | Not an error; returned on success. |
| 2 | UNKNOWN | 500 | Internal | Unknown error, this is sent if the error could not be identified as one of the errors described below |
| 3 | INVALID_ARGUMENT | 400 | Bad Request | The client specified an invalid argument. Note that this differs from FAILED_PRECONDITION. INVALID_ARGUMENT indicates arguments that are problematic regardless of the state of the system (e.g., a malformed file name). |
| 4 | DEADLINE_EXCEEDED | 504 | Gateway Timeout | The deadline expired before the operation could complete. |
| 5 | NOT_FOUND | 404 | Not found | Some requested entity (e.g. user or project) was not found. |
| 6 | ALREADY_EXISTS | 409 | Conflict | The entity that a client attempted to create (e.g. user or project) already exists. |
| 7 | PERMISSION_DENIED | 403 | Forbidden | The caller does not have permission to execute the specified operation. |
| 9 | FAILED_PRECONDITION | 400 | Bad Request | The operation was rejected because the system is not in a state required for the operation's execution. e.g a project that is already deactivated, should be deactivated |
| 12 | UNIMPLEMENTED | 501 | Not Implemented | The operation is not implemented or is not supported/enabled in this service. |
| 13 | INTERNAL | 500 | Internal | Internal errors. This means that some invariants expected by the underlying system have been broken. This error code is reserved for serious errors. |
| 14 | UNAVAILABLE | 503 | Service Unavailable | The service is currently unavailable. |
| 16 | UNAUTHENTICATED | 401 | Unauthorized | The request does not have valid authentication credentials for the operation. |
apps/docs/content/concepts/architecture/secrets.mdx
+1 -1
View File
@@ -25,7 +25,7 @@ ZITADEL uses the following principles when handling Secrets across their lifecyc
## Secrets Storage
By default ZITADEL stores secrets from its users, clients as well as its generated secrets like signing keys in the database.
By default ZITADEL stores secrets from its users, applications as well as its generated secrets like signing keys in the database.
To protect the secrets against extraction from database as well as database dumps they are encrypted with AES256.
<Callout>
apps/docs/content/concepts/features/selfservice.mdx
+1 -1
View File
@@ -73,7 +73,7 @@ Read more about [Service Users](/guides/integrate/service-users/authenticate-ser
## Logout
Users can terminate the session for all their users (logout).
A client can also implement this by calling the [specific endpoint](/apis/openidoauth/endpoints#end-session-endpoint).
An application can also implement this by calling the [specific endpoint](/apis/openidoauth/endpoints#end-session-endpoint).
## Profile
apps/docs/content/concepts/structure/_org_description.mdx
+1 -1
View File
@@ -8,7 +8,7 @@ ZITADEL is organized around the idea that:
Organizations in ZITADEL are therefore comparable to tenants of a system or organizational units of a directory based system.
You can use projects within your organization to manage the security context of closely related components, such as roles, grants and authorizations for multiple clients. You can set up multiple projects within your organization.
You can use projects within your organization to manage the security context of closely related components, such as roles, grants and authorizations for multiple applications. You can set up multiple projects within your organization.
ZITADEL allows you to give other organizations permission to manage certain aspects of a project within your organization on their own. This means you could set up a project with roles that should exist within your service/software, but allow another organization to allocate the roles to users within their own organization. As a service provider, you will find this feature useful, as it allows you to establish a self-service culture for your business customers.
apps/docs/content/concepts/structure/applications.mdx
+2 -2
View File
@@ -6,12 +6,12 @@ sidebar_label: Applications
import AppType from "../../guides/manage/console/_application-types.mdx";
Applications are the entry point to your project.
[Users](./users) either login into one of your clients and interact with them directly or use one of your APIs.
[Users](./users) either login into one of your applications and interact with them directly or use one of your APIs.
All applications share the roles and authorizations of their [project](./projects).
## Supported application types
ZITADEL supports the following client types:
ZITADEL supports the following application types:
<AppType components={props.components} />
apps/docs/content/examples/login/angular.mdx
+2 -2
View File
@@ -30,11 +30,11 @@ Continue and create the application.
### Client ID
After successful creation of the app, a pop-up will appear displaying the app's client ID. Copy the client ID, as you will need it to configure your Angular client.
After successful creation of the app, a pop-up will appear displaying the app's client ID. Copy the client ID, as you will need it to configure your Angular application.
## Angular setup
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Angular client.
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Angular application.
### Install Angular dependencies
apps/docs/content/examples/login/go.mdx
+2 -2
View File
@@ -40,13 +40,13 @@ Continue and create the application.
### Client ID
After successful creation of the app, a pop-up will appear displaying the app's client ID. Copy the client ID, as you will need it to configure your Go client.
After successful creation of the app, a pop-up will appear displaying the app's client ID. Copy the client ID, as you will need it to configure your Go application.
![Create app in management console - copy client_id](../../../public/img/go/app-create-clientid.png)
## Go setup
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Go client.
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Go application.
### Install ZITADEL Go SDK
apps/docs/content/examples/login/java-spring.mdx
+2 -2
View File
@@ -40,13 +40,13 @@ Continue and create the application.
### Client ID
After successful creation of the app, a pop-up will appear displaying the app's client ID. Copy the client ID, as you will need it to configure your Java client.
After successful creation of the app, a pop-up will appear displaying the app's client ID. Copy the client ID, as you will need it to configure your Java application.
![Create app in management console - copy client_id](../../../public/img/java-spring/app-create-clientid.png)
## Spring setup
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Spring client.
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Spring application.
This guide will reference the [example repository](https://github.com/zitadel/zitadel-java) and explain the necessary steps taken in there.
If your starting from scratch, you can use the Spring Initializer with the [following setup](https://start.spring.io/#!type=maven-project&language=java&platformVersion=3.2.1&packaging=jar&jvmVersion=17&dependencies=web,thymeleaf,security,oauth2-client,lombok) as a base.
apps/docs/content/examples/login/nextjs-b2b.mdx
+1 -1
View File
@@ -94,7 +94,7 @@ Replace the values as follows
`NEXTAUTH_URL`: Base url of this demo app (B2B portal); runs per default on [http://localhost:3000](http://localhost:3000)
`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 client.
`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`.
apps/docs/content/examples/login/nextjs.mdx
+1 -1
View File
@@ -56,7 +56,7 @@ Now that you have your web application configured on the ZITADEL side, you can g
### Configuration
NextAuth.js exposes a REST API which is used by your client.
NextAuth.js exposes a REST API which is used by your application.
To setup your configuration, create a file called `src/lib/auth.ts`.
You can directly import the ZITADEL provider from [next-auth](https://next-auth.js.org/providers/zitadel).
apps/docs/content/examples/login/react.mdx
+3 -3
View File
@@ -38,11 +38,11 @@ Continue and create the application.
### Copy Client ID
After successful creation of the app, make sure copy the client ID, as you will need it to configure your React client.
After successful creation of the app, make sure copy the client ID, as you will need it to configure your React application.
## Create a project role "admin" and assign it to your user
Also note the projects resource ID, as you will need it to configure your React client.
Also note the projects resource ID, as you will need it to configure your React application.
![](../../../public/img/react/project-role.png)
@@ -52,7 +52,7 @@ If you want to read your users roles from user info endpoint, make sure to enabl
## React setup
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your React client.
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your React application.
### Install React dependencies
apps/docs/content/examples/login/symfony.mdx
+1 -1
View File
@@ -71,7 +71,7 @@ The secret will not be displayed again, but you can regenerate one if you loose
## Setup new Symfony application
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Symfony client.
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Symfony application.
The example is build on a [generated Symfony web app](https://symfony.com/doc/current/setup.html#creating-symfony-applications), using the following command:
<Callout>
apps/docs/content/examples/login/vue.mdx
+3 -3
View File
@@ -39,13 +39,13 @@ Continue and create the application.
### Refresh Token and Client ID
After successful creation of the app, make sure you tick the checkbox to enable refresh tokens.
Also copy the client ID, as you will need it to configure your Vue client.
Also copy the client ID, as you will need it to configure your Vue application.
![](../../../public/img/vue/tick-refresh-token.png)
## Create a project role "admin" and assign it to your user
Also note the projects resource ID, as you will need it to configure your Vue client.
Also note the projects resource ID, as you will need it to configure your Vue application.
![](../../../public/img/vue/project-role.png)
@@ -53,7 +53,7 @@ Also note the projects resource ID, as you will need it to configure your Vue cl
## Vue setup
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Vue client.
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Vue application.
### Install Vue dependencies
apps/docs/content/examples/secure-api/go.mdx
+1 -1
View File
@@ -52,7 +52,7 @@ And make sure to download it, as you won't be able to retrieve it again.
![](../../../public/img/go/api-download_key.png)
Now we need to create a *Personal Access Token* to authenticate the client requests.
Now we need to create a *Personal Access Token* to authenticate the application requests.
On the user view, switch to *Service Users* and create a new one.
apps/docs/content/examples/secure-api/java-spring.mdx
+2 -2
View File
@@ -25,13 +25,13 @@ Select Basic Auth for authenticating at the Introspection Endpoint.
![Create app in management console](../../../public/img/java-spring/api-create-auth.png)
After successful creation of the app, a pop-up will appear displaying the app's client ID. Copy the client ID and secret, as you will need it to configure your Java client.
After successful creation of the app, a pop-up will appear displaying the app's client ID. Copy the client ID and secret, as you will need it to configure your Java application.
![Create api key in management console](../../../public/img/java-spring/api-create-clientid-secret.png)
## Spring Setup
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Spring client.
Now that you have configured your web application on the ZITADEL side, you can proceed with the integration of your Spring application.
This guide will reference the [example repository](https://github.com/zitadel/zitadel-java) and explain the necessary steps taken in there.
If your starting from scratch, you can use the Spring Initializer with the [following setup](https://start.spring.io/#!type=maven-project&language=java&platformVersion=3.2.1&packaging=jar&jvmVersion=17&dependencies=web,lombok,oauth2-resource-server) as a base.
apps/docs/content/guides/integrate/actions/testing-response-manipulation.mdx
+1 -1
View File
@@ -294,5 +294,5 @@ the [Sent information Response](./usage#sent-information-response) payload descr
## Conclusion
You have successfully set up a target and execution to manipulate API responses in your ZITADEL instance.
This feature can now be used to add necessary information for clients including the new login UI.
This feature can now be used to add necessary information for applications including the new login UI.
Find more information about the actions feature in the [API documentation](/concepts/features/actions_v2).
apps/docs/content/guides/integrate/back-channel-logout.mdx
+5 -5
View File
@@ -4,7 +4,7 @@ sidebar_label: Back-Channel Logout
---
The Back-Channel Logout implements [OpenID Connect Back-Channel Logout 1.0](https://openid.net/specs/openid-connect-backchannel-1_0.html)
and can be used to notify clients about session termination at the OpenID Provider. This guide will explain how
and can be used to notify applications about session termination at the OpenID Provider. This guide will explain how
back-channel logout is implemented inside ZITADEL and gives some usage examples.
<Callout type="info">
@@ -24,8 +24,8 @@ understanding on the following topics before starting with this guide:
## Concept
ZITADEL provides the possibility for OpenID Connect clients to be notified about the session termination, for example
if a user signs out from another client using the same SSO session.
This allows the client to also invalidate the user's session without the need for an active browser session.
if a user signs out from another application using the same SSO session.
This allows the application to also invalidate the user's session without the need for an active browser session.
![](../../../public/img/guides/back-channel-logout/back-channel-logout-flow.png)
@@ -57,7 +57,7 @@ provides the possibility to match the exact SSO session, which was terminated.
### Client
To enable the back-channel logout on a client, they simply need to register a `backchannel_logout_uri` as part of their
To enable the back-channel logout on an application, they simply need to register a `backchannel_logout_uri` as part of their
configuration, e.g. [creating an OIDC application](https://zitadel.com/docs/reference/api/management/management-service-add-oidc-app).
As soon as the URI is set, every new authorization request will register a back-channel notification to be sent once
@@ -66,7 +66,7 @@ the session is terminated by a user sign out.
## Back-Channel Request
When the session is terminated, ZITADEL will send back-channel logout requests asynchronously to every registered
client of the corresponding session.
application of the corresponding session.
The request is an `application/x-www-form-urlencoded` POST request to the registered URI including a `logout_token`
parameter in the body.
apps/docs/content/guides/integrate/identity-providers/azure-ad-oidc.mdx
+1 -1
View File
@@ -25,7 +25,7 @@ You will have to paste it in the Entra ID Client later.
You need to have access to an Entra ID Tenant. If you do not yet have one follow [this guide from Microsoft](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant) to create one for free.
### Register a new client
### 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.
apps/docs/content/guides/integrate/identity-providers/generic-oidc.mdx
+1 -1
View File
@@ -29,7 +29,7 @@ You will have to paste this URL in your external OIDC provider's application con
1. Log in to your external OIDC Provider's dashboard or management console.
2. Navigate to the applications, clients, or integrations section (name may vary depending on your provider).
3. Create a new application or client and select "OIDC" or "OpenID Connect" as the type.
3. Create a new application and select "OIDC" or "OpenID Connect" as the type.
4. Set a name for the application.
5. [Paste the ZITADEL Callback URL you copied before](#open-the-generic-oidc-provider-template) into the "redirect URIs" or "sign-in redirect URIs" field.
6. Save or copy the generated **Client ID** and **Client Secret**.
apps/docs/content/guides/integrate/identity-providers/google.mdx
+1 -1
View File
@@ -26,7 +26,7 @@ You will have to paste it in the Google Cloud Platform later.
## Google Configuration
### Register a new client
### Register a new application
1. Go to the Google Cloud Platform and choose your project: [https://console.cloud.google.com/apis/credentials](https://console.cloud.google.com/apis/credentials)
2. Click on "+ CREATE CREDENTIALS" and choose "OAuth client ID"
apps/docs/content/guides/integrate/login-ui/saml-standard.mdx
+2 -2
View File
@@ -130,7 +130,7 @@ Example Response POST-binding:
}
```
Which expects your client to do a POST call to the URL `https://myapp.example.com/acs` with the payload containing the following attributes:
Which expects your application to do a POST call to the URL `https://myapp.example.com/acs` with the payload containing the following attributes:
```
RelayState: "CncN92gdF6is7bak63thXOsn0MmJn7CLQeGKWaXZo2L8nJN0sPEHbb4I",
@@ -154,7 +154,7 @@ Example Response Redirect-binding:
}
```
Which expects your client to redirect to the url 'https://myapp.example.com/acs?RelayState=...&SAMLResponse=...' with all information as URL parameters.
Which expects your application to redirect to the url 'https://myapp.example.com/acs?RelayState=...&SAMLResponse=...' with all information as URL parameters.
### SAML Endpoints
apps/docs/content/guides/integrate/login/oidc/webkeys.mdx
+1 -1
View File
@@ -225,7 +225,7 @@ This strategy aims to fulfill the following requirements:
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.
Users that haven't logged in / refreshed tokens with the client app for that period,
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:
apps/docs/content/guides/integrate/retrieve-user-roles.mdx
+1 -1
View File
@@ -40,7 +40,7 @@ In order to access role information via the token you must include the right aud
An important concept in OpenID Connect (OIDC) is the 'audience' (`aud`) claim, which is part of the token payload. The `aud` claim identifies who or what this token is intended for. If the recipient (e.g., a resource server) does not identify itself with a value in the `aud` claim when this claim is present, then the token must be rejected.
The audience is essential in multi-tier systems, where you may authenticate with one client (in one project) but access resources from another client (in a different project) or when you are accessing ZITADEL’s management APIs. Without the correct audience in your token, you will run into errors, such as the ‘Invalid audience’ error in ZITADEL.
The audience is essential in multi-tier systems, where you may authenticate with one application (in one project) but access resources from another application (in a different project) or when you are accessing ZITADEL’s management APIs. Without the correct audience in your token, you will run into errors, such as the ‘Invalid audience’ error in ZITADEL.
You can determine the audience in two ways:
apps/docs/content/guides/integrate/service-users/authenticate-service-users.mdx
+3 -3
View File
@@ -51,7 +51,7 @@ ZITADEL supports two primary authentication methods for service users:
* ZITADEL validates the signature using the service user's public key.
* JWTs can include expiration dates and scopes to control access.
Follow our guide on using [private key JWT client authentication](./private-key-jwt) to get started authenticating service users and clients.
Follow our guide on using [private key JWT client authentication](./private-key-jwt) to get started authenticating service users and applications.
#### Benefits of private key JWT authentication
@@ -74,7 +74,7 @@ Follow our guide on using [private key JWT client authentication](./private-key-
* Presents a client ID and client secret associated with the service user.
* Simpler than the JWT profile in specific scenarios.
Follow our guide on using [client credentials grant](./client-credentials) to get started authenticating service users and clients.
Follow our guide on using [client credentials grant](./client-credentials) to get started authenticating service users and applications.
This method is still available in ZITADEL but is generally considered less secure than JWT due to:
@@ -86,7 +86,7 @@ This method is still available in ZITADEL but is generally considered less secur
* **Ready-to-use tokens:** Generated for specific service users and can be directly included in the authorization header of API requests.
* **Currently available only for machine users** (service users) and not regular human users.
Follow our guide on using [personal access tokens](./personal-access-token) to get started authenticating service users and clients.
Follow our guide on using [personal access tokens](./personal-access-token) to get started authenticating service users and applications.
PAT offer some benefits, such as:
apps/docs/content/guides/integrate/services/cloudflare-oidc.mdx
+2 -2
View File
@@ -12,7 +12,7 @@ Prerequisites:
- Existing ZITADEL instance, organization, and project. Follow our [get started](/guides/start/quickstart) guide to get started. If not present follow [this guide](/guides/start/quickstart)
- Existing Cloudflare account and [team domain](https://developers.cloudflare.com/cloudflare-one/glossary/#team-domain)
## Create the client in ZITADEL
## Create the application in ZITADEL
<CreateApp components={props.components} appType="web" authType="code" appName="Cloudflare" redirectURI="https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback"/>
@@ -23,7 +23,7 @@ Make sure to enable "User Info inside ID Token" on your application settings.
![](../../../../public/img/guides/integrate/services/user-info-inside-id-token.png)
<Callout>
Cloudflare will return an error "User email was not returned. API permissions are likely incorrect". Enable to send the user information inside the token on your client settings.
Cloudflare will return an error "User email was not returned. API permissions are likely incorrect". Enable to send the user information inside the token on your application settings.
</Callout>
## Configure Cloudflare Zero Trust Authentication
apps/docs/content/guides/integrate/token-introspection/_introspection-response.mdx
+12 -12
View File
@@ -1,17 +1,17 @@
Upon successful introspection, regardless of the token type or introspection method, a response with the boolean `active` is returned, indicating if the provided token is active and if the requesting client is part of the token audience. If `active` is true, further information will be provided:
| **Property** | **Description** |
| --- | --- |
| `aud` | The audience of the token |
| `client_id` | The client_id of the application the token was issued to |
| `exp` | Time the token expires (as unix time) |
| `iat` | Time the token was issued at (as unix time) |
| `iss` | Issuer of the token |
| `jti` | Unique id of the token |
| `nbf` | Time the token must not be used before (as unix time) |
| `scope` | Space delimited list of scopes granted to the token |
| `token_type` | Type of the inspected token. Value is always Bearer |
| `username` | ZITADEL's login name of the user. Consists of username@primarydomain |
| **Property** | **Description** |
|--------------|----------------------------------------------------------------------|
| `aud` | The audience of the token |
| `client_id` | The client_id of the application the token was issued to |
| `exp` | Time the token expires (as unix time) |
| `iat` | Time the token was issued at (as unix time) |
| `iss` | Issuer of the token |
| `jti` | Unique id of the token |
| `nbf` | Time the token must not be used before (as unix time) |
| `scope` | Space delimited list of scopes granted to the token |
| `token_type` | Type of the inspected token. Value is always Bearer |
| `username` | ZITADEL's login name of the user. Consists of username@primarydomain |
Depending on the granted scopes, additional information about the authorized user is provided.
apps/docs/content/guides/integrate/zitadel-apis/example-zitadel-api-with-dot-net.mdx
+3 -3
View File
@@ -40,9 +40,9 @@ Install the package via nuget
dotnet add package Zitadel.Api
```
### Create example client
### Create example application
Change the program.cs file to the content below. This will create a client for the management api and call its `GetMyUsers` function.
Change the program.cs file to the content below. This will create a application for the management api and call its `GetMyUsers` function.
The SDK will make sure you will have access to the API by retrieving a Bearer Token using JWT Profile with the provided scopes (`openid` and `urn:zitadel:iam:org:project:id:zitadel:aud`).
Make sure to fill the const `apiUrl`, and `personalAccessToken` with your own instance data. The used vars below are from a test instance, to show you how it should look.
@@ -86,7 +86,7 @@ result = await client.GetMyUserAsync(new());
Console.WriteLine($"User: {result.User}");
```
### Test client
### Test application
After you have configured everything correctly, you can simply start the example by:
apps/docs/content/guides/integrate/zitadel-apis/example-zitadel-api-with-go.mdx
+3 -3
View File
@@ -35,9 +35,9 @@ You need to add the SDK into Go Modules by:
go get -u github.com/zitadel/zitadel-go/v3
```
### Create example client
### Create example application
Create a new go file with the content below. This will create a client and call its `GetMyOrg` function on the ManagementService.
Create a new go file with the content below. This will create a application and call its `GetMyOrg` function on the ManagementService.
The SDK will make sure you will have access to the API by retrieving a Bearer Token using JWT Profile with the provided scopes (`openid` and `urn:zitadel:iam:org:project:id:zitadel:aud`).
```go reference
@@ -82,5 +82,5 @@ Now you can proceed implementing our APIs by adding more calls or using a differ
api.SessionService().CreateSession(ctx, &session.CreateSessionRequest{})
```
Checkout more [examples from the SDK](https://github.com/zitadel/zitadel-go/blob/next/example),
like how you can integrate the [client in your own API](https://github.com/zitadel/zitadel-go/blob/next/example/api/client/main.go)
like how you can integrate the [application in your own API](https://github.com/zitadel/zitadel-go/blob/next/example/api/client/main.go)
or refer to our [API Docs](/apis/introduction).
apps/docs/content/guides/manage/console/applications-overview.mdx
+2 -3
View File
@@ -13,7 +13,7 @@ import AppType from "./_application-types.mdx";
## What is an application?
Applications are the entry point to your [Project Overview](/guides/manage/console/projects-overview)
. Users either login into one of your clients (Frontend) and interact with them directly, or use one of your APIs (Backend).
. Users either login into one of your applications (Frontend) and interact with them directly, or use one of your APIs (Backend).
All applications within a project share the same **Roles** and **Authorizations**. This means you define a role once (e.g., `admin`) on the Project level, and it applies across all your web, mobile, and API applications.
@@ -23,7 +23,6 @@ To access your applications, navigate to your Project in the Management Console
alt="Granted project"
src="/docs/img/guides/console/applications.png"
width="750px"
/>
## Create an Application
@@ -38,7 +37,7 @@ To add an application to your project, click on the **New** button and select yo
## Application Types
ZITADEL offers five client types to cover different architectural patterns:
ZITADEL offers five application types to cover different architectural patterns:
<AppType components={props.components} />
apps/docs/content/guides/manage/console/applications.mdx
+2 -2
View File
@@ -11,7 +11,7 @@ import AppType from "./_application-types.mdx";
## What is an application?
Applications are the entry point to your project.
Users either login into one of your clients and interact with them directly or use one of your APIs.
Users either login into one of your applications and interact with them directly or use one of your APIs.
All applications share the roles and authorizations of their project.
To access your applications, navigate to your project and select your application.
@@ -34,7 +34,7 @@ To add an application to your project, click on the add button and select your a
## Application Types
At the moment ZITADEL offers five client types:
At the moment ZITADEL offers five application types:
<AppType components={props.components} />
apps/docs/content/guides/manage/console/default-settings.mdx
+1 -1
View File
@@ -154,7 +154,7 @@ The Login Policy defines how the login process should look like and which authen
### Default Redirect URI
The Default Redirect URI will be used, if a user calls the login page directly.
More specifically, typically a client will initiate login with an auth request.
More specifically, typically an application will initiate login with an auth request.
The auth request contains a client-id and a redirect uri, that must match the configuration in ZITADEL.
If there is no [auth request](https://zitadel.com/playgrounds/oidc), users will be redirected to the Default Redirect URI, which is by default `https://${CUSTOM_DOMAIN}/ui/console/`
apps/docs/content/guides/manage/console/organizations-overview.mdx
+1 -1
View File
@@ -20,7 +20,7 @@ In a B2B use case, an organization typically represents a business partner who r
## Structure and Delegation
### Projects within Organizations
You can use **Projects** within your organization to manage the security context of closely related components, such as roles, grants, and authorizations for multiple clients. You can set up multiple projects within a single organization.
You can use **Projects** within your organization to manage the security context of closely related components, such as roles, grants, and authorizations for multiple applications. You can set up multiple projects within a single organization.
### Organization Grants
ZITADEL allows you to give *other* organizations permission to manage certain aspects of a project within *your* organization.
apps/docs/content/guides/manage/console/projects.mdx
+1 -1
View File
@@ -12,7 +12,7 @@ import ProjectDescription from "../../../concepts/structure/_project_description
### Example
If you'd build a Point of Sales Platform, you would have one Project (maybe called `POS`) and all your applications (one Webapplication for administration, and your mobile applications for your users iOS and Android), would be part of it.
You would have to create roles for administration and your clients in this very project, and then create authorizations based on them.
You would have to create roles for administration and your applications in this very project, and then create authorizations based on them.
![](../../../../public/img/guides/console/posproject.png)
apps/docs/content/guides/manage/console/roles.mdx
+1 -1
View File
@@ -28,7 +28,7 @@ The **Group** is for making multiple roles selectable more easy.
<img src="/docs/img/guides/console/roles.png" width="750px" alt="Roles" />
> The role client is for an other application of the project `POS`, as all possible roles from your POS applications are defined in your project.
> The role client is for another application of the project `POS`, as all possible roles from your POS applications are defined in your project.
## Authorizations
apps/docs/content/guides/manage/customize/user-metadata.mdx
+2 -2
View File
@@ -21,7 +21,7 @@ You can do so by using [Console](../console/users) or [setting user metadata](/r
Most of the methods below require you to login with the correct user while setting some scopes.
Make sure you pick the right user when logging into the test application.
Use the [OIDC authentication request playground](https://zitadel.com/playgrounds/oidc) or the configuration of an [example client](/sdk-examples/introduction) to set the required scopes and receive a valid access token.
Use the [OIDC authentication request playground](https://zitadel.com/playgrounds/oidc) or the configuration of an [example application](/sdk-examples/introduction) to set the required scopes and receive a valid access token.
<Callout title="Getting a token">
In case you want to test out different settings configure an application with code flow (PKCE).
@@ -149,7 +149,7 @@ You can use the authentication service to request and search for the user's meta
The introspection endpoint and the token endpoint in the examples above do not require a special scope to access.
Yet when accessing the authentication service, you need to pass the [reserved scope](/apis/openidoauth/scopes#reserved-scopes) `urn:zitadel:iam:org:project:id:zitadel:aud` along with the authentication request.
This scope allows the user to access ZITADEL's APIs, specifically the authentication API that we need for this method.
Use the [OIDC authentication request playground](https://zitadel.com/playgrounds/oidc) or the configuration of an [example client](/sdk-examples/introduction) to set the required scopes and receive a valid access token.
Use the [OIDC authentication request playground](https://zitadel.com/playgrounds/oidc) or the configuration of an [example application](/sdk-examples/introduction) to set the required scopes and receive a valid access token.
<Callout title="Invalid audience">
If you get the error "invalid audience (APP-Zxfako)", then you need to add the reserved scope `urn:zitadel:iam:org:project:id:zitadel:aud` to your authentication request.
apps/docs/content/guides/solution-scenarios/b2c.mdx
+1 -1
View File
@@ -86,7 +86,7 @@ We'd appreciate if you could contribute to our repo with translations of your la
### Projects and applications
As our Hosted Login is a separate authentication screen, you have to determine how you are directing your users from your applications.
ZITADEL's Applications live under ZITADEL's Projects. You may add multiple applications for your different client-types (Native, Web, User Agent, or API). When setting up your applications consider reading our guide about [Authentication Flows](../integrate/login/oidc/login-users).
ZITADEL's Applications live under ZITADEL's Projects. You may add multiple applications for your different application-types (Native, Web, User Agent, or API). When setting up your applications consider reading our guide about [Authentication Flows](../integrate/login/oidc/login-users).
### Access Control
apps/docs/content/guides/start/quickstart.mdx
+15 -3
View File
@@ -13,9 +13,11 @@ This sample app implements the [OIDC PKCE](/guides/integrate/login/oidc/login-us
- Login: Exchanges a code challenge for an access token via ZITADEL.
- Authorize: Uses the token to retrieve profile data from the userinfo endpoint.
- Logout: Clears the local session and revokes the token.
## Get Started with ZITADEL Cloud
Set up your ZITADEL account and organization to begin managing identities for your applications.
### 1. Create your Account and Organization
You first need access to the ZITADEL Cloud Customer Portal.
@@ -32,6 +34,7 @@ This is the administrative hub for managing your billing, teams, and instances.
Complete the brief onboarding questions.
This data helps us prioritize the development of new features, SDKs, and integrations that matter most to our community.
![](../../../public/img/guides/quickstart/onboarding_questions.png)
### 3. Create your ZITADEL instance
@@ -48,10 +51,12 @@ Follow these steps to deploy your first instance:
5. **Deploy**: Review your configuration and click Create Instance.
![Create Instance](../../../public/img/guides/quickstart/cloud_create_instance.png)
### 4. Create your Project and Application
In ZITADEL, [**Applications**](/guides/manage/console/applications-overview) are grouped into [**Projects**](/guides/manage/console/projects-overview).
This allows multiple apps (like a React frontend and a Go backend) to share the same roles and authorizations.
This allows multiple applications (like a React frontend and a Go backend) to share the same roles and authorizations.
#### Launch the Management Console
Click **Create your app**. This opens the Management Console for your instance in a new tab.
@@ -62,6 +67,7 @@ Log in using the Admin credentials you just created.
- **Name**: Enter a name (e.g., Project1).
- **Framework**: Select React (or choose Other if your stack isn't listed).
- **Continue**: Click the Continue button.
![](../../../public/img/guides/quickstart/create_project_react.png)
#### Step 2: Review Default Configuration
@@ -74,6 +80,7 @@ ZITADEL automatically configures the best security settings for your selected fr
![](../../../public/img/guides/quickstart/project_config_overview_react.png)
### 5. Collect your Integration Keys
To connect your React application to ZITADEL, you need two primary configuration values.
These are typically stored as environment variables in your project.
@@ -85,7 +92,9 @@ These are typically stored as environment variables in your project.
![Get URLs](../../../public/img/guides/quickstart/project_urls.png)
## Integrate ZITADEL into your React App
### How the Authentication Flow Works
ZITADEL handles the complexity of the OIDC handshake so your app stays secure without manual token management.
1. **Login**: App redirects the user to ZITADEL with a PKCE challenge.
2. **Auth**: User authenticates on the ZITADEL hosted login page.
@@ -94,6 +103,7 @@ ZITADEL handles the complexity of the OIDC handshake so your app stays secure wi
5. **Logout**: The app clears local tokens and terminates the ZITADEL session.
### 1. Prerequisites
- [Node.js](https://nodejs.org/): v16 or later.
- Code Editor: [VS Code](https://code.visualstudio.com/) or similar
- [Yarn](https://yarnpkg.com/): This project uses Yarn for dependency management.
@@ -103,7 +113,8 @@ ZITADEL handles the complexity of the OIDC handshake so your app stays secure wi
Clone the repository and move into the project directory:
```bash
git clone https://github.com/zitadel/zitadel-react.git
cd zitadel-react```
cd zitadel-react
```
### 3. Build and Install
@@ -113,7 +124,8 @@ Since this repo contains the SDK source, you need to build the library before ru
cd lib && yarn install && yarn build
# Install example app dependencies
cd .. && yarn install```
cd .. && yarn install
```
### 4. Configure your Credentials
apps/docs/content/legal/policies/privacy-policy.mdx
+1 -1
View File
@@ -162,7 +162,7 @@ Necessary cookies provide basic functionality such as:
We use cookies for website analytics purposes in order to operate, maintain, and improve the Services for you.
We use third-party providers, mentioned in our [List of Subprocessors](https://trust.zitadel.com/subprocessors), that collect and process certain analytics data on our behalf.
These third-party providers helps us understand how you engage with the Services and may also collect information about your use of other websites, apps, and online resources.
These third-party providers helps us understand how you engage with the Services and may also collect information about your use of other websites, applications, and online resources.
You can opt out by managing your cookie consent through our Services or a third-party tool of your choice.
apps/docs/content/self-hosting/deploy/docker-compose.yaml
+1 -1
View File
@@ -25,7 +25,7 @@ services:
ZITADEL_DATABASE_POSTGRES_USER_PASSWORD: zitadel
ZITADEL_DATABASE_POSTGRES_USER_SSL_MODE: disable
# By configuring a login client, the setup job creates a user of type machine with the role IAM_LOGIN_CLIENT.
# By configuring a login application, the setup job creates a user of type machine with the role IAM_LOGIN_CLIENT.
# It writes a PAT to the path specified in ZITADEL_FIRSTINSTANCE_LOGINCLIENTPATPATH.
# The PAT is passed to the login container via the environment variable ZITADEL_SERVICE_USER_TOKEN_FILE.
ZITADEL_FIRSTINSTANCE_LOGINCLIENTPATPATH: /current-dir/login-client.pat
apps/docs/content/self-hosting/manage/http2.mdx
+1 -1
View File
@@ -6,7 +6,7 @@ sidebar_label: HTTP/2 Support
ZITADEL follows a strict API first approach and makes heavy use of the modern API framework called [gRPC](https://grpc.io/).
Besides gRPC all APIs are also available in an openapi Rest fashion as well as in gRPC-web for compatibility towards browser integrations.
To make use of gRPC it is vital to allow your clients to communicate with ZITADEL with [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2).
To make use of gRPC it is vital to allow your applications to communicate with ZITADEL with [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2).
Sometimes you need to configure explicitly that you want to use HTTP/2 if you run ZITADEL behind a reverse proxy and below you should find examples for different vendors and projects.
apps/docs/content/support/troubleshooting.mdx
+1 -1
View File
@@ -38,7 +38,7 @@ This error message refers to the audience claim (`aud`) of your token.
This claim identifies the audience, i.e. the resource server, that this token is intended for.
If a resource server does not identify itself with a value in the "aud" claim when this claim is present, then the must be rejected (see [RFC7519](https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3) for more details).
You might encounter this error message from ZITADEL, typically when you authenticated with a client in one project and trying to access an application in another project.
You might encounter this error message from ZITADEL, typically when you authenticated with an application in one project and trying to access an application in another project.
You need add a specific [reserved scope](/apis/openidoauth/scopes#reserved-scopes) to add the projectID to the audience of the access token.
The two scenarios should help you troubleshoot this issue: