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

chore: naming custom domain (#11383)

Browse Source 
# Which Problems Are Solved

As part of the consistent naming effort, this PR focuses on "Custom
Domains".

# How the Problems Are Solved

- All terms referring to a domain identifying an instance were changed
to "Custom Domain" or "custom domain".
- All placeholders were changed to `${CUSTOM_DOMAIN}` or
`$CUSTOM_DOMAIN` (if escaping was not possible)
- Some other placeholders were change to the same style.
- One occurrence of custom domain was changed to organization domain to
prevent misunderstandings.

# Additional Changes

None

# Additional Context

- closes #11296 
- customer portal is fixed on
https://github.com/zitadel/website/pull/1570
- angular example is updated on
https://github.com/zitadel/zitadel-angular/pull/29
This commit is contained in:
Livio Spring
2026-01-20 10:26:57 +05:30
committed by GitHub
parent be57a08aaa
commit 8c0d6c6817
105 changed files with 315 additions and 315 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/base.yaml
+1 -1
View File
@@ -2,4 +2,4 @@ openapi: 3.1.0
info:
version: v2
servers:
- url: https://$CUSTOM-DOMAIN
- url: https://$CUSTOM_DOMAIN
docs/docs/apis/introduction.mdx
+2 -2
View File
@@ -270,7 +270,7 @@ In the table below you can see the URI of those calls.
## Domains
ZITADEL hosts everything under a single domain: `{instance}.zitadel.cloud` or your custom domain `${CUSTOM_DOMAIN}`
ZITADEL hosts everything under a single domain: `{instance}.zitadel.cloud` or your Custom Domain `${CUSTOM_DOMAIN}`
The domain is used as the OIDC issuer and as the base url for the gRPC and REST APIs, the Login and Console UI, which you'll find under `${CUSTOM_DOMAIN}/ui/console/`.
@@ -278,7 +278,7 @@ Are you self-hosting and having troubles with _Instance not found_ errors? [Chec
## API path prefixes
If you run ZITADEL on a custom domain, you may want to reuse that domain for other applications.
If you run ZITADEL on a Custom Domain, you may want to reuse that domain for other applications.
For easy copying to your reverse proxy configuration, here is the list of URL path prefixes, ZITADEL uses.
```yaml
docs/docs/apis/openidoauth/authn-methods.md
+2 -2
View File
@@ -46,7 +46,7 @@ JWT
| Claim | Example | Description |
|:------|:---------------------------|:----------------------------------------------------------------------------------------------------------------|
| aud | `"https://$CUSTOM-DOMAIN"` | String or Array of intended audiences MUST include ZITADEL's issuing domain |
| 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 |
| iss | `"78366401571920522@acme"` | String which represents the requesting party (owner of the key), normally the `clientID` from the json key file |
@@ -56,7 +56,7 @@ JWT
{
"iss": "78366401571920522@acme",
"sub": "78366401571920522@acme",
"aud": "https://$CUSTOM-DOMAIN",
"aud": "https://${CUSTOM_DOMAIN}",
"exp": 1605183582,
"iat": 1605179982
}
docs/docs/apis/openidoauth/claims.md
+2 -2
View File
@@ -47,7 +47,7 @@ Please check below the matrix for an overview where which scope is asserted.
| Claims | Example | Description |
|:-------------------|:---------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| acr | TBA | TBA |
| act | `{"iss": "$CUSTOM-DOMAIN","sub": "259241944654282754"}` | JSON object describing the actor from the `actor_token` after [token exchange](/docs/guides/integrate/token-exchange#actor-token) |
| act | `{"iss": "${CUSTOM_DOMAIN}","sub": "259241944654282754"}` | JSON object describing the actor from the `actor_token` after [token exchange](/docs/guides/integrate/token-exchange#actor-token) |
| address | `Lerchenfeldstrasse 3, 9014 St. Gallen` | TBA |
| amr | `pwd mfa` | Authentication Method References as defined in [RFC8176](https://tools.ietf.org/html/rfc8176) <br/> `password` value is deprecated, please check `pwd` |
| aud | `69234237810729019` | The audience of the token, by default all client id's and the project id are included |
@@ -61,7 +61,7 @@ Please check below the matrix for an overview where which scope is asserted.
| gender | `other` | Gender 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 |
docs/docs/apis/openidoauth/grant-types.md
+2 -2
View File
@@ -78,7 +78,7 @@ JWT
| Claim | Example | Description |
| :---- | :------------------------- | :------------------------------------------------------------------------------------------------------------ |
| aud | `"https://$CUSTOM-DOMAIN"` | String or Array of intended audiences MUST include ZITADEL's issuing domain |
| 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 |
| iss | `"77479219772321307"` | String which represents the requesting party (owner of the key), normally the `userId` from the json key file |
@@ -88,7 +88,7 @@ JWT
{
"iss": "77479219772321307",
"sub": "77479219772321307",
"aud": "https://$CUSTOM-DOMAIN",
"aud": "https://${CUSTOM_DOMAIN}",
"exp": 1605183582,
"iat": 1605179982
}
docs/docs/apis/saml/endpoints.md
+14 -14
View File
@@ -4,7 +4,7 @@ title: SAML Endpoints in ZITADEL
## SAML 2.0 metadata
The SAML Metadata is located within the issuer domain. This would give us $CUSTOM-DOMAIN/saml/v2/metadata.
The SAML Metadata is located within the issuer domain. This would give us `${CUSTOM_DOMAIN}/saml/v2/metadata`.
This metadata contains all the information defined in the spec.
@@ -13,14 +13,14 @@ spec.** [Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0
## Certificate endpoint
$CUSTOM-DOMAIN/saml/v2/certificate
`${CUSTOM_DOMAIN}/saml/v2/certificate`
The certificate endpoint provides the certificate which is used to sign the responses for download, for easier use with
different service providers which want the certificate separately instead of inside the metadata.
## SSO endpoint
$CUSTOM-DOMAIN/saml/v2/SSO
`${CUSTOM_DOMAIN}/saml/v2/SSO`
The SSO endpoint is the starting point for all initial user authentications. The user agent (browser) will be redirected
to this endpoint to authenticate the user.
@@ -33,23 +33,23 @@ spec.** [Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0
### Required request parameters
| Parameter | Description |
|---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| RelayState | (Optional) ID to associate the exchange with the original request. |
| Parameter | Description |
|-------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| RelayState | (Optional) ID to associate the exchange with the original request. |
| SAMLRequest | The request made to the SAML IDP. (base64 encoded) |
| SigAlg | Algorithm used to sign the request, only if binding is 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' as signature has to be provided es separate parameter. (base64 encoded) |
| Signature | Signature of the request as parameter with 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' binding. (base64 encoded) |
| SigAlg | Algorithm used to sign the request, only if binding is 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' as signature has to be provided es separate parameter. (base64 encoded) |
| Signature | Signature of the request as parameter with 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' binding. (base64 encoded) |
### Successful response
Depending on the content of the request the response comes back in the requested binding, but the content is the same.
| Parameter | Description |
|---------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| RelayState | ID to associate the exchange with the original request. |
| SAMLResponse | The response form the SAML IDP. (base64 encoded) |
| SigAlg | Algorithm used to sign the response, only if binding is 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' as signature has to be provided es separate parameter. (base64 encoded) |
| Signature | Signature of the response as parameter with 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' binding. (base64 encoded) |
| Parameter | Description |
|--------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| RelayState | ID to associate the exchange with the original request. |
| SAMLResponse | The response form the SAML IDP. (base64 encoded) |
| SigAlg | Algorithm used to sign the response, only if binding is 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' as signature has to be provided es separate parameter. (base64 encoded) |
| Signature | Signature of the response as parameter with 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' binding. (base64 encoded) |
### Error response
docs/docs/concepts/features/audit-trail.md
+1 -1
View File
@@ -36,7 +36,7 @@ The same view is available on several other objects such as organization or proj
### Event View
Administrators can see all events across an instance and filter them directly in [Console](/docs/guides/manage/console/console-overview).
Go to your default settings and then click on the Tab **Events** to open the Event Viewer or browse to $CUSTOM-DOMAIN/ui/console/events
Go to your default settings and then click on the Tab **Events** to open the Event Viewer or browse to $CUSTOM_DOMAIN/ui/console/events
![Event viewer](/img/concepts/audit-trail/event-viewer.png)
docs/docs/concepts/features/console.md
+1 -1
View File
@@ -6,7 +6,7 @@ sidebar_label: Console
The ZITADEL console is a web-based interface designed to facilitate the management and administration of ZITADEL resources and configurations.
It serves as a central hub where administrators can perform various tasks related to identity and access management within their organization's infrastructure.
The console is available by navigating to the [custom domain](/docs/concepts/features/custom-domain) of your instance and appending the path `/ui/console`.
The console is available by navigating to the [Custom Domain](/docs/concepts/features/custom-domain) of your instance and appending the path `/ui/console`.
Administrators can [restrict end-users from accessing the console](/docs/guides/solution-scenarios/restrict-console).
Here's an overview of what the console enables users to do:
docs/docs/concepts/features/custom-domain.md
+6 -6
View File
@@ -1,13 +1,13 @@
---
title: Custom domain
sidebar_label: Custom domain
title: Custom Domain
sidebar_label: Custom Domain
---
A ZITADEL custom domain refers to the ability for organizations to personalize the authentication experience by using their own domain name rather than the default ZITADEL domain.
A ZITADEL Custom Domain refers to the ability for organizations to personalize the authentication experience by using their own domain name rather than the default ZITADEL domain.
This feature allows organizations to maintain their brand identity throughout the authentication process, providing a seamless and consistent user experience.
By configuring a custom domain within ZITADEL, organizations can replace the default authentication URLs with their own domain, such as "login.example.com" or "auth.companyname.com".
By configuring a Custom Domain within ZITADEL, organizations can replace the default authentication URLs with their own domain, such as "login.example.com" or "auth.companyname.com".
This not only enhances the overall user experience but also reinforces the organization's brand presence. Additionally, custom domains can contribute to trust and credibility, as users are more likely to recognize and trust URLs associated with the organization rather than generic domains. Overall, ZITADEL's custom domain feature empowers organizations to tailor the authentication process to align with their brand identity and user expectations.
This not only enhances the overall user experience but also reinforces the organization's brand presence. Additionally, Custom Domains can contribute to trust and credibility, as users are more likely to recognize and trust URLs associated with the organization rather than generic domains. Overall, ZITADEL's Custom Domain feature empowers organizations to tailor the authentication process to align with their brand identity and user expectations.
Learn how to [configure a custom domain in ZITADEL Cloud](/docs/guides/manage/cloud/instances#add-custom-domain) or how to configure [custom domain when self-hosting](/docs/self-hosting/manage/custom-domain).
Learn how to [configure a Custom Domain in ZITADEL Cloud](/docs/guides/manage/cloud/instances#add-custom-domain) or how to configure [Custom Domain when self-hosting](/docs/self-hosting/manage/custom-domain).
docs/docs/concepts/features/passkeys.md
+1 -1
View File
@@ -32,6 +32,6 @@ Imagine signing in without passwords! Passkeys, replacing traditional passwords,
* Passkey support is still evolving in browsers and platforms. Check compatibility for your target audience.
* ZITADEL actively develops its passkey features. Stay updated with documentation and releases.
* Passkeys are bound to your domain, thus we recommend configuring a [custom domain](/docs/concepts/features/custom-domain.md) before setting up passkeys.
* Passkeys are bound to your domain, thus we recommend configuring a [Custom Domain](/docs/concepts/features/custom-domain.md) before setting up passkeys.
Don't hesitate to ask if you have further questions about integrating passkeys in your ZITADEL application!
docs/docs/concepts/features/selfservice.md
+1 -1
View File
@@ -78,7 +78,7 @@ A client can also implement this, by calling the [specific endpoint](/apis/openi
## Profile
These actions are available for authenticated users only.
ZITADEL provides a self-service UI for the user profile out-of-the box under the path _$CUSTOM-DOMAIN/ui/console/users/me_.
ZITADEL provides a self-service UI for the user profile out-of-the box under the path _$CUSTOM_DOMAIN/ui/console/users/me_.
You can also implement your own version in your application by using our APIs.
### Change password
docs/docs/concepts/structure/_org_description.mdx
+1 -1
View File
@@ -14,4 +14,4 @@ ZITADEL allows you to give other organizations permission to manage certain aspe
![Organization Grant](/img/concepts/objects/organization_grants.png)
Each organization has its own pool of usernames, which includes human and service users, for its domain (`{username}@{domainname}.{zitadeldomain}`). A username is unique within your organization. You can configure ZITADEL to use your own domain, and simplify user experience (`{loginname}@{yourdomain.tld}`).
Each organization has its own pool of usernames, which includes human and service users, for its domain (`{username}@{OrganizationDomain}.$CUSTOM_DOMAIN`). A username is unique within your organization. You can configure ZITADEL to use your own domain, and simplify user experience (`{loginname}@{yourdomain.tld}`).
docs/docs/concepts/structure/instance.mdx
+1 -1
View File
@@ -26,7 +26,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](/apis/resources/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.
docs/docs/examples/identity-proxy/oauth2-proxy.md
+1 -1
View File
@@ -43,7 +43,7 @@ provider = "oidc"
user_id_claim = "sub" #uses the subject as ID instead of the email
provider_display_name = "ZITADEL"
redirect_url = "http://127.0.0.1:4180/oauth2/callback"
oidc_issuer_url = "https://$CUSTOM-DOMAIN"
oidc_issuer_url = "https://$CUSTOM_DOMAIN"
upstreams = [
"https://example.corp.com"
]
docs/docs/examples/login/go.md
+2 -2
View File
@@ -122,14 +122,14 @@ https://github.com/zitadel/zitadel-go/blob/next/example/app/templates/profile.ht
### Start your application
You will need to provide some values for the program to run:
- `domain`: Your ZITADEL custom domain, e.g. my-domain.zitadel.cloud
- `domain`: Your ZITADEL Custom Domain, e.g. my-domain.zitadel.cloud
- `key`: Random secret string. Used for symmetric encryption of state parameters, cookies and PKCE.
- `clientID`: The clientID provided by ZITADEL
- `redirectURI`: The redirectURI registered at ZITADEL
- `port`: The port on which the API will be accessible, default it 8089
```bash
go run main.go --domain <your domain> --key <key> -- clientID <clientID> --redirectURI <redirectURI>
go run main.go --domain <custom domain> --key <key> -- clientID <clientID> --redirectURI <redirectURI>
```
This could look like:
docs/docs/examples/login/java-spring.md
+1 -1
View File
@@ -144,7 +144,7 @@ In case you've created your own application and depending on your development se
mvn clean package -DskipTests
```
You will need to provide the `issuer-uri` (your ZITADEL domain) and the `client-id` previously created:
You will need to provide the `issuer-uri` (your Custom Domain) and the `client-id` previously created:
```bash
java \
docs/docs/examples/login/nextjs-b2b.md
+13 -13
View File
@@ -22,7 +22,7 @@ First we need to create an organization that holds the Vendor's users, projects
### Vendor Organization
Navigate to `https://{YourDomain}.zitadel.cloud/ui/console/orgs` (replace \{YourDomain}), and click on the button "New".
Navigate to `https://$CUSTOM_DOMAIN.zitadel.cloud/ui/console/orgs` (replace $CUSTOM_DOMAIN), and click on the button "New".
Toggle the setting "Use your personal account as organization owner".
Enter the name `Demo-Vendor`, and click "Create". Then click on that organization.
@@ -31,7 +31,7 @@ Enter the name `Demo-Vendor`, and click "Create". Then click on that organizatio
To setup this sample you have to create a project and an application in the vendor organization (`Demo-Vendor`) first.
Open the Console (`https://{YourDomain}.zitadel.cloud/ui/console/projects`) and create a new project. Let's call it `Portal`.
Open the 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`.
@@ -81,12 +81,12 @@ Create a file `.env.local` and copy paste the following:
```text
NEXTAUTH_URL=http://localhost:3000
NEXT_PUBLIC_ZITADEL_ISSUER=https://{YourDomain}.zitadel.cloud
ZITADEL_API=https://{YourDomain}.zitadel.cloud
ORG_ID={YourOrgId}
PROJECT_ID={YourProjectId}
ZITADEL_CLIENT_ID={YourClientID}
SERVICE_ACCOUNT_ACCESS_TOKEN={YourServiceAccountSecret}
NEXT_PUBLIC_ZITADEL_ISSUER=https://$CUSTOM_DOMAIN.zitadel.cloud
ZITADEL_API=https://$CUSTOM_DOMAIN.zitadel.cloud
ORG_ID=${YOUR_ORG_ID}
PROJECT_ID=${PROJECT_ID}
ZITADEL_CLIENT_ID=${CLIENT_ID}
SERVICE_ACCOUNT_ACCESS_TOKEN=${SERVICE_ACCOUNT_SECRET}
NEXTAUTH_SECRET=randomsecret
```
@@ -98,13 +98,13 @@ Replace the values as follows
`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 `{YourOrgId}` by selecting the `Demo-Vendor` organization in Console. `{YourOrgId}` 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 `{YourProjectId}` by clicking on "Projects" in the navigation and select the Project `Portal`. `{YourProjectId}` 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`. `{YourClientID}` 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, labelled "Client ID" and has the format `12345678@portal`.
`SERVICE_ACCOUNT_ACCESS_TOKEN`: Setup a service user, add a Personal Access Token and copy the secret here (see below).
`SERVICE_ACCOUNT_ACCESS_TOKEN`: Set up a service user, add a Personal Access Token and copy the secret here (see below).
## Install and Run
@@ -152,7 +152,7 @@ Login with your user on the customer organization to validate the setup.
### Organization Grant
Switch to the `Demo-Vendor` organization, select Projects in the navigation, and click on `Portal` and then `Grants`.
[Grant all roles of the Project](/guides/manage/console/projects-overview#granted-projects-b2b) to the organization `demo-customer.{YourDomain}.zitadel.cloud`.
[Grant all roles of the Project](/guides/manage/console/projects-overview#granted-projects-b2b) to the organization `demo-customer.$CUSTOM_DOMAIN.zitadel.cloud`.
### Authorization
docs/docs/examples/login/symfony.md
+1 -1
View File
@@ -375,7 +375,7 @@ OIDC_CLIENT_ID="248680248240075805@dev"
OIDC_CLIENT_SECRET="BJPhEJULSUXseC4geqg5Yg4wWMoy7RgZKar86mbIpt8ZekC5kixMzYGcXLDeeJv7"
```
> The well-known URL needs to be adjusted to your own custom domain.
> The well-known URL needs to be adjusted to your own Custom Domain.
Activate the route that is used as callback by the OIDC bundle:
docs/docs/examples/secure-api/go.md
+2 -2
View File
@@ -98,7 +98,7 @@ https://github.com/zitadel/zitadel-go/blob/next/example/api/http/main.go
```
You will need to provide some values for the program to run:
- `domain`: Your ZITADEL custom domain, e.g. https://my-domain.zitadel.cloud
- `domain`: Your ZITADEL Custom Domain, e.g. https://my-domain.zitadel.cloud
- `key`: The path to the downloaded key.json
- `port`: The port on which the API will be accessible, default it 8089
@@ -107,7 +107,7 @@ You will need to provide some values for the program to run:
After you have configured everything correctly, you can simply start the example by:
```bash
go run main.go --domain <your domain> --key <path>
go run main.go --domain <custom domain> --key <path>
```
This could look like:
docs/docs/examples/secure-api/java-spring.md
+1 -1
View File
@@ -91,7 +91,7 @@ In case you've created your own application and depending on your development se
mvn clean package -DskipTests
```
You will need to provide the `introspection-uri` (your ZITADEL domain> /oauth/v2/introspect), the `client-id` and `client-secret` previously created:
You will need to provide the `introspection-uri` ($CUSTOM_DOMAIN/oauth/v2/introspect), the `client-id` and `client-secret` previously created:
```bash
java \
docs/docs/guides/integrate/actions/testing-event.md
+3 -3
View File
@@ -74,7 +74,7 @@ target can be created as follows:
See [Create a target](/apis/resources/action_service_v2/action-service-create-target) for more detailed information.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -98,7 +98,7 @@ condition.
See [Set an execution](/apis/resources/action_service_v2/action-service-set-execution) for more detailed information.
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/executions' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -120,7 +120,7 @@ Now that you have set up the target and execution, you can test it by creating a
by calling the ZITADEL API to create a human user.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/users/new' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/integrate/actions/testing-function-manipulation.md
+2 -2
View File
@@ -100,7 +100,7 @@ As you see in the example above the target is created with HTTP and port '8090'
See [Create a target](/apis/resources/action_service_v2/action-service-create-target) for more detailed information.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -124,7 +124,7 @@ condition.
See [Set an execution](/apis/resources/action_service_v2/action-service-set-execution) for more detailed information.
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/executions' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/integrate/actions/testing-function.md
+2 -2
View File
@@ -78,7 +78,7 @@ As you see in the example above the target is created with HTTP and port '8090'
See [Create a target](/apis/resources/action_service_v2/action-service-create-target) for more detailed information.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -102,7 +102,7 @@ condition.
See [Set an execution](/apis/resources/action_service_v2/action-service-set-execution) for more detailed information.
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/executions' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/integrate/actions/testing-request-manipulation.md
+4 -4
View File
@@ -129,7 +129,7 @@ As you see in the example above the target is created with HTTP and port '8090'
See [Create a target](/apis/resources/action_service_v2/action-service-create-target) for more detailed information.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -152,7 +152,7 @@ To call the target just created before, with the intention to manipulate the req
See [Set an execution](/apis/resources/action_service_v2/action-service-set-execution) for more detailed information.
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/executions' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -174,7 +174,7 @@ Now that you have set up the target and execution, you can test it by creating a
by calling the ZITADEL API to create a human user.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/users/new' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -203,7 +203,7 @@ Your server should now manipulate the request to something like the following. C
the [Sent information Request](./usage#sent-information-request) payload description.
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/users/new' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/users/new' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/integrate/actions/testing-request-signature.mdx
+5 -5
View File
@@ -47,7 +47,7 @@ See [Create a target](/apis/resources/action_service_v2/action-service-create-ta
Specify the `payloadType` according to the implementation you want to test: `PAYLOAD_TYPE_JSON`, `PAYLOAD_TYPE_JWT`, or `PAYLOAD_TYPE_JWE`.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -85,7 +85,7 @@ openssl rsa -pubout -in private_key.pem -out public_key.pem
Then upload the public key to ZITADEL using the following command. Replace `<TargetID>` with the ID of the target you created earlier.
Use the base64 encoded content of the `public_key.pem` file as the value for `publicKey`.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets/<TargetID>/publickeys' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets/<TargetID>/publickeys' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -96,7 +96,7 @@ curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets/<TargetID>/publickeys
Be sure to also activate the public key for the target using the returned `<KeyID>` from the previous request:
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/targets/<TargetID>/publickeys/<KeyID>/activate' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/targets/<TargetID>/publickeys/<KeyID>/activate' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>'
@@ -110,7 +110,7 @@ condition.
See [Set an execution](/apis/resources/action_service_v2/action-service-set-execution) for more detailed information.
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/executions' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -157,7 +157,7 @@ Now that you have set up the target and execution, you can test it by creating a
by calling the ZITADEL API to create a human user.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/users/new' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/integrate/actions/testing-request.md
+3 -3
View File
@@ -78,7 +78,7 @@ As you see in the example above the target is created with HTTP and port '8090'
See [Create a target](/apis/resources/action_service_v2/action-service-create-target) for more detailed information.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -102,7 +102,7 @@ condition.
See [Set an execution](/apis/resources/action_service_v2/action-service-set-execution) for more detailed information.
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/executions' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -124,7 +124,7 @@ Now that you have set up the target and execution, you can test it by creating a
by calling the ZITADEL API to create a human user.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/users/new' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/integrate/actions/testing-response-manipulation.md
+2 -2
View File
@@ -144,7 +144,7 @@ target can be created as follows:
See [Create a target](/apis/resources/action_service_v2/action-service-create-target) for more detailed information.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -168,7 +168,7 @@ we define an execution with a response condition.
See [Set an execution](/apis/resources/action_service_v2/action-service-set-execution) for more detailed information.
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/executions' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/integrate/actions/testing-response.md
+3 -3
View File
@@ -78,7 +78,7 @@ As you see in the example above the target is created with HTTP and port '8090'
See [Create a target](/apis/resources/action_service_v2/action-service-create-target) for more detailed information.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -102,7 +102,7 @@ condition.
See [Set an execution](/apis/resources/action_service_v2/action-service-set-execution) for more detailed information.
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/executions' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -124,7 +124,7 @@ Now that you have set up the target and execution, you can test it by creating a
by calling the ZITADEL API to create a human user.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/users/new' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/users/new' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/integrate/actions/webhook-site-setup.md
+3 -3
View File
@@ -80,7 +80,7 @@ As shown in the example above, the target is created with HTTP and port '8090'.
See [Create a target](/apis/resources/action_service_v2/action-service-create-target) for more detailed information. Notice that the `endpoint` is your Webhook.site URL.
```shell
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -117,7 +117,7 @@ See [Set an execution](/apis/resources/action_service_v2/action-service-set-exec
Here, `<TargetID returned>` is the `id` from the previous step.
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/executions' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/executions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -142,7 +142,7 @@ Now that you have set up the target and execution, you can test it by creating a
Here, we are creating a user via the API:
```shell
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/users/human' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/users/human' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/integrate/authenticated-mongodb-charts.md
+1 -1
View File
@@ -29,7 +29,7 @@ Configure ZITADEL as your _Custom JWT Provider_ following the [MongoDB docs](htt
Configure the following values:
- Signing Algorithm: RS256
- Signing Key: JWK or JWKS URL
- JWKS: https://$CUSTOM-DOMAIN/oauth/v2/keys
- JWKS: https://$CUSTOM_DOMAIN/oauth/v2/keys
- Audience: Your app's client ID which you copied when you created the ZITADEL app
Your configuration should look similar to this:
docs/docs/guides/integrate/back-channel-logout.mdx
+1 -1
View File
@@ -85,7 +85,7 @@ The following Claims are used within the Logout Token:
| Claim | Example | Description |
|--------|----------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|
| iss | `$CUSTOM-DOMAIN` | Issuer Identifier |
| iss | `${CUSTOM_DOMAIN}` | Issuer Identifier |
| sub | `77776025198584418` | Subject Identifier (the user who signed out) |
| aud | `69234237810729019` | Audience(s), will always contain your client_id |
| iat | `1311280970` | Issued at time |
docs/docs/guides/integrate/identity-providers/apple.mdx
+1 -1
View File
@@ -39,7 +39,7 @@ You will have to paste it in the Apple service later.
4. Add a description and a unique identifier and click "register"
5. Select your registered service from the list and enable sign in with Apple, then click "configure"
6. Choose the previously created App in the Primary App ID List
7. Add your custom domain in the domains and subdomains field
7. Add your Custom Domain in the domains and subdomains field
- Example domain for `https://acme-gzoe4x.zitadel.cloud` would look like this: `acme-gzoe4x.zitadel.cloud`
8. [Paste the ZITADEL Callback URL you copied before](#open-the-apple-identity-provider-template) to the Return URLs
docs/docs/guides/integrate/identity-providers/jwt_idp.md
+2 -2
View File
@@ -74,7 +74,7 @@ The authentication flow with JWT IdP looks like this:
// 2. Prepare the ZITADEL endpoint URL and copy all query params
const userUrl = new URL(request.url);
// Important: The ZITADEL_JWT_IDP_ENDPOINT should be your ZITADEL custom domain plus "/idps/jwt"
// Important: The ZITADEL_JWT_IDP_ENDPOINT should be your ZITADEL Custom Domain plus "/idps/jwt"
// For example: https://accounts.test.com/idps/jwt
const zitadelUrl = new URL(env.ZITADEL_JWT_IDP_ENDPOINT);
userUrl.searchParams.forEach((v, k) => zitadelUrl.searchParams.set(k, v));
@@ -99,7 +99,7 @@ The authentication flow with JWT IdP looks like this:
}
```
*(Replace `getJwtForCurrentSession` with your logic for retrieving/creating a JWT from the user's WAF session.
Note: `env.ZITADEL_JWT_IDP_ENDPOINT` should be set to the custom domain of your ZITADEL instance
Note: `env.ZITADEL_JWT_IDP_ENDPOINT` should be set to the Custom Domain of your ZITADEL instance
with the `/idps/jwt` path, e.g. `https://accounts.test.com/idps/jwt`.)*
5. **ZITADEL receives and validates the JWT (Server-side):**
docs/docs/guides/integrate/identity-providers/linkedin_oauth.mdx
+1 -1
View File
@@ -25,7 +25,7 @@ import TestSetup from './_test_setup.mdx';
4. Go to the Auth Settings of the App and add the following URL to the "Authorized redirect URLs"
- Login V1: `${CUSTOM_DOMAIN}/ui/login/login/externalidp/callback`
- Example redirect url for the domain `https://acme.zitadel.cloud` would look like this: `https://acme.zitadel.cloud/ui/login/login/externalidp/callback`
- Login V2: `{LOGINGV2_DOMAIN}/idps/callback`
- Login V2: `${LOGINGV2_DOMAIN}/idps/callback`
- In this case the url would look like this: `https://acme.zitadel.cloud/idps/callback`
5. Verify the app as your company
6. In the Auth - OAuth 2.0 scopes section you should see `openid`, `profile` and `email` listed
docs/docs/guides/integrate/login/hosted-login.mdx
+2 -2
View File
@@ -76,7 +76,7 @@ While the hosted login page provides a default authentication interface out-of-t
Developers can customize elements such as logos, colors, and messaging to ensure a seamless integration with their application's user interface.
:::info Customization and Branding
The login page can be changed by customizing different branding aspects and you can define a custom domain for the login (eg, login.acme.com).
The login page can be changed by customizing different branding aspects and you can define a Custom Domain for the login (eg, login.acme.com).
By default, the displayed branding is defined [based on the user's domain](/docs/guides/solution-scenarios/domain-discovery). In case you want to show the branding of a specific organization by default, you need to either pass a primary domain scope (`urn:zitadel:iam:org:domain:primary:{domainname}`) with the authorization request, or define the behavior on your Project's settings.
:::
@@ -157,7 +157,7 @@ For the first implementation we have excluded the following features:
#### Step-by-step Guide
**Using the new login:** To use the new login without changing your current setup, the easiest way is to visit `https://<CUSTOM_DOMAIN>/ui/v2/login` on your Zitadel Cloud custom domain.
**Using the new login:** To use the new login without changing your current setup, the easiest way is to visit `https://${CUSTOM_DOMAIN}/ui/v2/login` on your Zitadel Cloud Custom Domain.
You can also activate the v2 login for your apps, so users are redirected to `/ui/v2/login` for authentication.
**Customizing the new login:** The easiest way to actually customizing it is to fork the https://github.com/zitadel/zitadel repo and use the [Deploy with Vercel button](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#login-deploy) to run your login code on Vercel.
docs/docs/guides/integrate/login/oidc/logout.md
+1 -1
View File
@@ -37,7 +37,7 @@ If you have specified some post_logout_redirect_uris on your client you have to
So ZITADEL is able to read the configured redirect uris.
```
GET $CUSTOM-DOMAIN/oidc/v1/end_session
GET ${CUSTOM_DOMAIN}/oidc/v1/end_session
?id_token_hint={id_token}
&post_logout_redirect_uri=https://rp.example.com/logged_out
&state=random_string
docs/docs/guides/integrate/login/oidc/webkeys.md
+7 -7
View File
@@ -106,7 +106,7 @@ When the request does not contain any specific configuration,
[RSA](#rsa) is used as default with the default options as described below:
```bash
curl -L 'https://$CUSTOM-DOMAIN/v2/web_keys' \
curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -130,7 +130,7 @@ The RSA generator config takes two enum values.
For example, to create a RSA web key with the size of 3072 bits and the SHA512 algorithm (RS512):
```bash
curl -L 'https://$CUSTOM-DOMAIN/v2/web_keys' \
curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -154,7 +154,7 @@ The ECDSA generator config takes a single `curve` enum value which determines bo
For example, to create a ECDSA web key with a P-256 curve and the SHA256 algorithm:
```bash
curl -L 'https://$CUSTOM-DOMAIN/v2/web_keys' \
curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -178,7 +178,7 @@ Clients which support both curves must inspect `crv` header value to assert the
For example, to create a ed25519 web key:
```bash
curl -L 'https://$CUSTOM-DOMAIN/v2/web_keys' \
curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -240,11 +240,11 @@ For the sake of this example we will use simplified IDs and restrict timestamps
After one month, on 2025-02-01, we wish to activate the next available key and create a new key to be available for activation next month. This fulfills requirements 1 and 2.
```bash
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/web_keys/2/_activate' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/web_keys/2/_activate' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>'
curl -L 'https://$CUSTOM-DOMAIN/v2/web_keys' \
curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -276,7 +276,7 @@ In addition to the activate and create calls we made on this iteration,
we can now safely delete the oldest key, as both requirement 3 and 4 are now fulfilled:
```bash
curl -L -X DELETE 'https://$CUSTOM-DOMAIN/v2/web_keys/1' \
curl -L -X DELETE 'https://${CUSTOM_DOMAIN}/v2/web_keys/1' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>'
```
docs/docs/guides/integrate/onboarding/b2b.mdx
+1 -1
View File
@@ -170,7 +170,7 @@ Per default the user will automatically get "ORG_OWNER".
#### Example Request
```bash
curl -L -X POST 'https://$CUSTOM-DOMAIN/admin/v1/orgs/_setup' \
curl -L -X POST 'https://${CUSTOM_DOMAIN}/admin/v1/orgs/_setup' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/integrate/service-users/client-credentials.md
+2 -2
View File
@@ -34,14 +34,14 @@ You will need to craft a POST request to ZITADEL's token endpoint:
```bash
curl --request POST \
--url https://$CUSTOM-DOMAIN/oauth/v2/token \
--url https://${CUSTOM_DOMAIN}/oauth/v2/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data grant_type=client_credentials \
--data scope='openid profile' \
--user "$CLIENT_ID:$CLIENT_SECRET"
```
* `CUSTOM_DOMAIN` should be set to your [custom domain](/docs/concepts/features/custom-domain)
* `CUSTOM_DOMAIN` should be set to your [Custom Domain](/docs/concepts/features/custom-domain)
* `grant_type` should be set to `client_credentials`
* `scope` should contain any [Scopes](/apis/openidoauth/scopes) you want to include, but must include `openid`. For this example, please include `profile`
* `CLIENT_ID` and `CLIENT_SECRET` should be set with the values shown in Console when generating a new secret to enable [basic authentication](/docs/apis/openidoauth/authn-methods)
docs/docs/guides/integrate/service-users/personal-access-token.md
+1 -1
View File
@@ -50,7 +50,7 @@ In this example we read the organization of the service user.
```bash
curl --request GET \
--url $CUSTOM-DOMAIN/management/v1/orgs/me \
--url ${CUSTOM_DOMAIN}/management/v1/orgs/me \
--header 'Authorization: Bearer {PAT}'
```
docs/docs/guides/integrate/service-users/private-key-jwt.md
+2 -2
View File
@@ -108,7 +108,7 @@ Payload:
{
"iss": "100507859606888466",
"sub": "100507859606888466",
"aud": "https://$CUSTOM-DOMAIN",
"aud": "https://${CUSTOM_DOMAIN}",
"iat": [Current UTC timestamp, e.g. 1605179982, must be no older than 1 hour],
"exp": [Expiration UTC timestamp, e.g. 1605183582]
}
@@ -165,7 +165,7 @@ With the encoded JWT from the previous step, craft a POST request to ZITADEL's t
```bash
curl --request POST \
--url https:/$CUSTOM-DOMAIN/oauth/v2/token \
--url https:/${CUSTOM_DOMAIN}/oauth/v2/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer \
--data scope='openid' \
docs/docs/guides/integrate/services/aws-saml.md
+1 -1
View File
@@ -45,7 +45,7 @@ can connect to ZITADEL as a SAML2 IDP.
4. Download the ZITADEL-used certificate to sign the responses, so that AWS can validation the signature.
You can download the certificate from following
URL: \{your_instance_domain}/saml/v2/certificate
URL: `${CUSTOM_DOMAIN}/saml/v2/certificate`
5. Then upload the ".crt"-file to AWS and click "next".
docs/docs/guides/integrate/services/gitlab-saml.md
+1 -1
View File
@@ -51,7 +51,7 @@ Check your application, if everything is correct, press "Create".
Complete the configuration as follows:
- `Identity provider single sign-on URL`: $CUSTOM-DOMAIN/saml/v2/SSO
- `Identity provider single sign-on URL`: `${CUSTOM_DOMAIN}/saml/v2/SSO`
- `Certificate fingerprint`: You need to download the certificate from \{your_instance_domain}/saml/v2/certificate and create a SHA1 fingerprint
Save the changes.
docs/docs/guides/integrate/services/google-workspace.md
+12 -12
View File
@@ -39,7 +39,7 @@ Download the public certificate from your ZITADEL instance by requesting `${CUST
wget ${CUSTOM_DOMAIN}/saml/v2/certificate -O idp.crt
```
Always replace `${CUSTOM_DOMAIN}` with your custom domain.
Always replace `${CUSTOM_DOMAIN}` with your Custom Domain.
Use the following configuration
@@ -119,24 +119,24 @@ Open the Google settings for [SSO with third-party IdP](https://admin.google.com
![SSO with third-party IdP](/img/guides/integrate/services/google-workspace-sso-overview.png)
Download the public certificate from your ZITADEL instance by requesting `$YOUR_DOMAIN/saml/v2/certificate`
Download the public certificate from your ZITADEL instance by requesting `${CUSTOM_DOMAIN}/saml/v2/certificate`
```bash
wget $YOUR_DOMAIN/saml/v2/certificate -O idp.crt
wget ${CUSTOM_DOMAIN}/saml/v2/certificate -O idp.crt
```
Always replace `$YOUR_DOMAIN` with your custom domain.
Always replace `${CUSTOM_DOMAIN}` with your Custom Domain.
Use the following configuration
| Setting | Value |
| --- | --- |
| SSO profile name | ZITADEL SSO |
| IDP entity ID | $YOUR_DOMAIN/saml/v2/metadata |
| Sign-in page URL | $YOUR_DOMAIN/saml/v2/SSO |
| Sign-out page URL | $YOUR_DOMAIN/saml/v2/SLO |
| Change password URL | $YOUR_DOMAIN/ui/console/users/me?id=security |
| Verification Certificate | Upload the certificate (idp.crt) |
| Setting | Value |
|--------------------------|----------------------------------------------------|
| SSO profile name | ZITADEL SSO |
| IDP entity ID | `${CUSTOM_DOMAIN}`/saml/v2/metadata |
| Sign-in page URL | `${CUSTOM_DOMAIN}`/saml/v2/SSO |
| Sign-out page URL | `${CUSTOM_DOMAIN}`/saml/v2/SLO |
| Change password URL | `${CUSTOM_DOMAIN}`/ui/console/users/me?id=security |
| Verification Certificate | Upload the certificate (idp.crt) |
Now go ahead and click *SAVE*
docs/docs/guides/integrate/token-exchange.mdx
+2 -2
View File
@@ -190,7 +190,7 @@ These preparation steps are needed for all Token Exchange interaction, including
As Token Exchange is still a beta feature, the feature needs to be enabled for your instance by an `IAM_OWNER` first:
```bash
curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/features/instance' \
curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/features/instance' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <IAM_OWNER_TOKEN>' \
@@ -829,7 +829,7 @@ And the `subject_token`:
}
```
In both cases the issuer is the web application, the audience must be the zitadel domain. For the assertion the subject is the application and for the subject token the subject is the impersonated user.
In both cases the issuer is the web application, the audience must be the Custom Domain. For the assertion the subject is the application and for the subject token the subject is the impersonated user.
Response:
docs/docs/guides/integrate/token-introspection/private-key-jwt.mdx
+14 -14
View File
@@ -82,10 +82,10 @@ To use Private Key JWT for introspection, you must register your client applicat
```
{
"type": "application",
"keyId": "<YOUR_KEY_ID>",
"key": "-----BEGIN RSA PRIVATE KEY-----\n<YOUR_PRIVATE_KEY>\n-----END RSA PRIVATE KEY-----\n",
"appId": "<YOUR_APP_ID>",
"clientId": "<YOUR_CLIENT_ID>"
"keyId": "${YOUR_KEY_ID}",
"key": "-----BEGIN RSA PRIVATE KEY-----\n${YOUR_PRIVATE_KEY}\n-----END RSA PRIVATE KEY-----\n",
"appId": "${YOUR_APP_ID}",
"clientId": "${YOUR_CLIENT_ID}"
}
```
@@ -111,11 +111,11 @@ To introspect an access token in ZITADEL, your backend must authenticate by prov
**Required request parameters:**
| **Parameter** | **Description** |
|------------------------- |---------------------------------------------------------------------------------------------------------------------|
| `client_assertion` | The JWT assertion created and signed as described below. |
| `client_assertion_type` | Must be `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
| `token` | The access token you want to introspect. |
| **Parameter** | **Description** |
|-------------------------|------------------------------------------------------------------|
| `client_assertion` | The JWT assertion created and signed as described below. |
| `client_assertion_type` | Must be `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
| `token` | The access token you want to introspect. |
### Creating the Client Assertion (JWT)
@@ -125,16 +125,16 @@ The `client_assertion` parameter is a signed JWT with the following structure:
```json
{
"alg": "RS256",
"kid": "<YOUR_KEY_ID>"
"kid": "${YOUR_KEY_ID}"
}
```
**Payload:**
```json
{
"iss": "<YOUR_CLIENT_ID>",
"sub": "<YOUR_CLIENT_ID>",
"aud": "https://${YOUR_DOMAIN}", // Your ZITADEL issuer URL
"iss": "${YOUR_CLIENT_ID}",
"sub": "${YOUR_CLIENT_ID}",
"aud": "https://${CUSTOM_DOMAIN}", // Your ZITADEL issuer URL / Custom Domain
"exp": 1605183582, // Expiry (Unix timestamp)
"iat": 1605179982 // Issued at (Unix timestamp, not older than 1 hour)
}
@@ -153,7 +153,7 @@ Make a POST request to the introspection endpoint, sending the above parameters:
```bash
curl --request POST \
--url ${YOUR_DOMAIN}/oauth/v2/introspect \
--url ${CUSTOM_DOMAIN}/oauth/v2/introspect \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer \
--data client_assertion=eyJhbGciOiJSUzI1Ni... \
docs/docs/guides/integrate/zitadel-apis/_accessing_zitadel_api.md
+3 -3
View File
@@ -7,7 +7,7 @@ You will need to craft a POST request to ZITADEL's token endpoint:
```bash
curl --request POST \
--url https://$CUSTOM-DOMAIN/oauth/v2/token \
--url https://${CUSTOM_DOMAIN}/oauth/v2/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic ${BASIC_AUTH}' \
--data grant_type=client_credentials \
@@ -40,7 +40,7 @@ You will need to craft a POST request to ZITADEL's token endpoint:
```bash
curl --request POST \
--url https://$CUSTOM-DOMAIN/oauth/v2/token \
--url https://${CUSTOM_DOMAIN}/oauth/v2/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic ${BASIC_AUTH}' \
--data grant_type=client_credentials \
@@ -68,7 +68,7 @@ Content-Type: application/json
```bash
curl --request GET \
--url $CUSTOM-DOMAIN/management/v1/orgs/me \
--url ${CUSTOM_DOMAIN}/management/v1/orgs/me \
--header "Authorization: Bearer $TOKEN"
```
docs/docs/guides/integrate/zitadel-apis/access-zitadel-apis.md
+5 -5
View File
@@ -109,7 +109,7 @@ A sample request will look like this
```bash {5}
curl --request POST \
--url $CUSTOM-DOMAIN/oauth/v2/token \
--url ${CUSTOM_DOMAIN}/oauth/v2/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer \
--data scope='openid profile urn:zitadel:iam:org:project:id:zitadel:aud' \
@@ -140,7 +140,7 @@ In the following example, we read the organization of the service user.
```bash
curl --request GET \
--url $CUSTOM-DOMAIN/management/v1/orgs/me \
--url ${CUSTOM_DOMAIN}/management/v1/orgs/me \
--header 'Authorization: Bearer ${TOKEN}'
```
@@ -181,7 +181,7 @@ You will need to craft a POST request to ZITADEL's token endpoint:
```bash {6}
curl --request POST \
--url https://$CUSTOM-DOMAIN/oauth/v2/token \
--url https://${CUSTOM_DOMAIN}/oauth/v2/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic ${BASIC_AUTH}' \
--data grant_type=client_credentials \
@@ -212,7 +212,7 @@ In this example we read the organization of the service user.
```bash
curl --request GET \
--url $CUSTOM-DOMAIN/management/v1/orgs/me \
--url ${CUSTOM_DOMAIN}/management/v1/orgs/me \
--header 'Authorization: Bearer ${TOKEN}'
```
@@ -225,7 +225,7 @@ In this example, we read the organization of the service user.
```bash
curl --request GET \
--url $CUSTOM-DOMAIN/management/v1/orgs/me \
--url ${CUSTOM_DOMAIN}/management/v1/orgs/me \
--header 'Authorization: Bearer {PAT}'
```
docs/docs/guides/integrate/zitadel-apis/access-zitadel-system-api.md
+2 -2
View File
@@ -89,7 +89,7 @@ The JWT payload will need to contain the following claims:
{
"iss": "<userid>",
"sub": "<userid>",
"aud": "<https://$CUSTOM-DOMAIN>",
"aud": "<https://${CUSTOM_DOMAIN}>",
"exp": <now+1h>,
"iat": <now>
}
@@ -125,7 +125,7 @@ Now that you configured ZITADEL and created a JWT, you can call the System API a
```bash
curl --request POST \
--url $CUSTOM-DOMAIN/system/v1/instances/_search \
--url ${CUSTOM_DOMAIN}/system/v1/instances/_search \
--header 'Authorization: Bearer {token}' \
--header 'Content-Type: application/json'
```
docs/docs/guides/integrate/zitadel-apis/event-api.md
+7 -7
View File
@@ -24,7 +24,7 @@ To further restrict your result you can add the following filters:
```bash
curl --request POST \
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
--url ${CUSTOM_DOMAIN}/admin/v1/events/_search \
--header "Authorization: Bearer $TOKEN"
```
@@ -34,7 +34,7 @@ To be able to filter for the different event types ZITADEL knows, you can reques
```bash
curl --request POST \
--url $CUSTOM-DOMAIN/admin/v1/events/types/_search \
--url ${CUSTOM_DOMAIN}/admin/v1/events/types/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json' \
'
@@ -70,7 +70,7 @@ To be able to filter for the different aggregate types (resources) ZITADEL knows
```bash
curl --request POST \
--url $CUSTOM-DOMAIN/admin/v1/aggregates/types/_search \
--url ${CUSTOM_DOMAIN}/admin/v1/aggregates/types/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json'
```
@@ -101,7 +101,7 @@ This example shows you how to get all events from users, filtered with the creat
```bash
curl --request POST \
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
--url ${CUSTOM_DOMAIN}/admin/v1/events/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json' \
--data '{
@@ -124,7 +124,7 @@ Sessions without tokens events may by created during implicit flow with ID Token
```bash
curl --request POST \
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
--url ${CUSTOM_DOMAIN}/admin/v1/events/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json' \
--data '{
@@ -148,7 +148,7 @@ The following example shows you how you could use the events search to get all e
```bash
curl --request POST \
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
--url ${CUSTOM_DOMAIN}/admin/v1/events/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json' \
--data '{
@@ -177,7 +177,7 @@ In this case these are the following events:
```bash
curl --request POST \
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
--url ${CUSTOM_DOMAIN}/admin/v1/events/_search \
--header "Authorization: Bearer $TOKEN" \
--header 'Content-Type: application/json' \
--data '{
docs/docs/guides/integrate/zitadel-apis/example-zitadel-api-with-go.md
+1 -1
View File
@@ -49,7 +49,7 @@ https://github.com/zitadel/zitadel-go/blob/next/example/client/cli/cli.go
After you have configured everything correctly, you can simply start the example by:
```bash
go run cli.go --domain <your domain> --key <path>
go run cli.go --domain <custom domain> --key <path>
```
This could look like:
docs/docs/guides/manage/cloud/instances.md
+8 -8
View File
@@ -16,7 +16,7 @@ To be able to add more instances please upgrade to "ZITADEL Pro".
## Overview
The overview shows all the instances that are registered for your customer.
You can directly see the custom domain and data region.
You can directly see the Custom Domain and data region.
With a click on an instance you get to the detail of the chosen instance.
@@ -34,7 +34,7 @@ Click on the new button above the instance table to create a new instance.
3. Instance created! You can now see the details of your first instance.
:::info
Every new instance gets a generated domain of the form [instancename][randomnumber].zitadel.cloud
Every new instance gets a generated Custom Domain of the form [instancename][randomnumber].zitadel.cloud
:::
![New Instance](/img/manuals/portal/customer_portal_new_instance.gif)
@@ -65,11 +65,11 @@ You can also upgrade manually at any time.
### Add Custom Domain
We recommend register a custom domain to access your ZITADEL instance.
The primary custom domain of your ZITADEL instance will be the issuer of the instance. All other custom domains can be used to access the instance itself
We recommend register a Custom Domain to access your ZITADEL instance.
The primary Custom Domain of your ZITADEL instance will be the issuer of the instance. All other Custom Domains can be used to access the instance itself
1. Browse to the "Custom Domains" Tab
2. Click **Add domain**
2. Click **Add Custom Domain**
3. Enter the domain you want and select the instance where the domain should belong to
4. In the next screen you will get all the information you will have to add to your DNS provider to verify your domain
@@ -80,14 +80,14 @@ Be aware that it has some impacts if you change the primary domain of your insta
1. The urls and issuer have to change in your app
2. Passkey authentication is based on the domain, if you change it, your users will not be able to login with the registered passkey authentication
![Add custom domain](/img/manuals/portal/customer_portal_add_domain.png)
![Add Custom Domain](/img/manuals/portal/customer_portal_add_domain.png)
#### Verify Custom Domain
As soon as you have added your custom domain you will have to verify it, by adding a CNAME record to your DNS provider.
As soon as you have added your Custom Domain you will have to verify it, by adding a CNAME record to your DNS provider.
1. Go to your DNS provider
2. Add a new CNAME record (You can find the target on the detail page of your instance)
3. After adding the CNAME you need to wait till the domain is verified (this can take some time)
You will now be able to use the added custom domain to access your ZITADEL instance
You will now be able to use the added Custom Domain to access your ZITADEL instance
docs/docs/guides/manage/console/console-overview.mdx
+1 -1
View File
@@ -11,7 +11,7 @@ While the Console is primarily a tool for administrators, it can also be accesse
## Accessing the Console
The console is available by navigating to the [custom domain](/docs/concepts/features/custom-domain) of your instance and appending the path `/ui/console`.
The console is available by navigating to the [Custom Domain](/docs/concepts/features/custom-domain) of your instance and appending the path `/ui/console`.
## Navigation and Context
docs/docs/guides/manage/console/default-settings.mdx
+3 -3
View File
@@ -87,7 +87,7 @@ You can configure on which changes the users will be notified. The text of the m
### SMTP
On each instance we configure our default SMTP provider. To make sure, that you only send some E-Mails from domains you own, you need to add a custom domain on your instance.
On each instance we configure our default SMTP provider. To make sure, that you only send some E-Mails from domains you own, you need to add a Custom Domain on your instance.
You can configure many SMTP providers using templates for popular providers. The templates will add known settings like host, port or default user and will suggest values for user and/or password.
@@ -102,7 +102,7 @@ Email delivery through this service may be **delayed or temporarily unstable**.
For any **production setup**, you must configure your own SMTP provider to ensure reliable and consistent email delivery.
:::
Go to the ZITADEL [customer portal](https://zitadel.cloud) to configure a custom domain.
Go to the ZITADEL [customer portal](https://zitadel.cloud) to configure a Custom Domain.
To configure your custom SMTP please fill the following fields:
@@ -277,7 +277,7 @@ If it is set to false, all registered domain will automatically be created as ve
### SMTP Sender Address matches Custom Domain
If enabled, the SMTP server address must match the instance's primary custom domain.
If enabled, the SMTP server address must match the instance's primary Custom Domain.
With that you can ensure that users receive notifications from the same domain that is used for login.
### Use email as username
docs/docs/guides/manage/console/organizations.mdx
+1 -1
View File
@@ -23,7 +23,7 @@ If you choose your logged in user as organization manager, a membership for the
alt="Select Organization"
/>
If you want to enable your customers to create their organization by themselves, we provide a creation form for an organization. `<https://$CUSTOM-DOMAIN/ui/login/register/org`
If you want to enable your customers to create their organization by themselves, we provide a creation form for an organization. `https://${CUSTOM_DOMAIN}/ui/login/register/org`
The customer needs to fill in the form with the organization name and the contact details.
<img
docs/docs/guides/manage/console/overview.mdx
+1 -1
View File
@@ -5,7 +5,7 @@ sidebar_label: Overview
## What is console?
Console is the Dashboard UI for your instance. It can be accessed from all configured custom domains, defined in the Customer Portal.
Console is the Dashboard UI for your instance. It can be accessed from all configured Custom Domains, defined in the Customer Portal.
The console is used to configure global default settings and can be used by multiple Managers.
Read more about [Console Managers](./managers) here.
docs/docs/guides/manage/customize/notification-providers.mdx
+4 -4
View File
@@ -43,7 +43,7 @@ A provider with HTTP type will send the messages and the data to a pre-defined w
First [add a new SMS Provider of type HTTP](/apis/resources/admin/admin-service-add-sms-provider-http) to create a new HTTP provider that can be used to send SMS messages:
```bash
curl -L 'https://$CUSTOM-DOMAIN/admin/v1/sms/http' \
curl -L 'https://${CUSTOM_DOMAIN}/admin/v1/sms/http' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -60,7 +60,7 @@ A provider with HTTP type will send the messages and the data to a pre-defined w
To use the HTTP provider you need to [activate the SMS provider](/apis/resources/admin/admin-service-activate-sms-provider):
```bash
curl -L 'https://$CUSTOM-DOMAIN/admin/v1/sms/:id/_activate' \
curl -L 'https://${CUSTOM_DOMAIN}/admin/v1/sms/:id/_activate' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -77,7 +77,7 @@ A provider with HTTP type will send the messages and the data to a pre-defined w
First [add a new Email Provider of type HTTP](/apis/resources/admin/admin-service-add-email-provider-http) to create a new HTTP provider that can be used to send Email messages:
```bash
curl -L 'https://$CUSTOM-DOMAIN/admin/v1/email/http' \
curl -L 'https://${CUSTOM_DOMAIN}/admin/v1/email/http' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
@@ -94,7 +94,7 @@ A provider with HTTP type will send the messages and the data to a pre-defined w
To use the HTTP provider you need to [activate the Email provider](/apis/resources/admin/admin-service-activate-email-provider):
```bash
curl -L 'https://$CUSTOM-DOMAIN/admin/v1/email/:id/_activate' \
curl -L 'https://${CUSTOM_DOMAIN}/admin/v1/email/:id/_activate' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
docs/docs/guides/manage/customize/user-metadata.md
+7 -7
View File
@@ -50,7 +50,7 @@ Request the user information by calling the [userinfo endpoint](/docs/apis/openi
```bash
curl --request GET \
--url "https://$CUSTOM-DOMAIN/oidc/v1/userinfo" \
--url "https://${CUSTOM_DOMAIN}/oidc/v1/userinfo" \
--header "Authorization: Bearer $ACCESS_TOKEN"
```
@@ -161,10 +161,10 @@ If you get the error "invalid audience (APP-Zxfako)", then you need to add the r
You can request the user's metadata with the [List My Metadata](/docs/apis/resources/auth/auth-service-list-my-metadata) method:
```bash
curl -L -X POST "https://$CUSTOM-DOMAIN/auth/v1/users/me/metadata/_search" \
curl -L -X POST "https://${CUSTOM_DOMAIN}/auth/v1/users/me/metadata/_search" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
--data-raw '{
"query": {
"offset": "0",
@@ -174,7 +174,7 @@ curl -L -X POST "https://$CUSTOM-DOMAIN/auth/v1/users/me/metadata/_search" \
"queries": [
{
"keyQuery": {
"key": "$METADATA_KEY",
"key": "${METADATA_KEY}",
"method": "TEXT_QUERY_METHOD_EQUALS"
}
}
@@ -182,9 +182,9 @@ curl -L -X POST "https://$CUSTOM-DOMAIN/auth/v1/users/me/metadata/_search" \
}'
```
Replace `$ACCESS_TOKEN` with your user's access token.
Replace `$CUSTOM-DOMAIN` with your ZITADEL instance's url.
Replace `$METADATA_KEY` with they key you want to search for (f.e. "ContractNumber")
Replace `${ACCESS_TOKEN}` with your user's access token.
Replace `${CUSTOM_DOMAIN}` with your ZITADEL instance's url.
Replace `${METADATA_KEY}` with they key you want to search for (f.e. "ContractNumber")
:::info Get all metadata
You can omit the queries array to retrieve all metadata key-value pairs.
docs/docs/guides/manage/customize/user-schema.md
+3 -3
View File
@@ -30,7 +30,7 @@ We can do so by calling the [create user schema endpoint](/docs/apis/resources/u
with the following data. Make sure to provide an `access_token` with an `IAM_OWNER` role.
```bash
curl -X POST "https://$CUSTOM-DOMAIN/v3alpha/user_schemas" \
curl -X POST "https://${CUSTOM_DOMAIN}/v3alpha/user_schemas" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H "Authorization: Bearer $ACCESS_TOKEN" \
@@ -92,7 +92,7 @@ Finally, we call the [update user schema endpoint](/docs/apis/resources/user_sch
with the following data. Be sure to provide the id of the previously created schema.
```bash
curl -X PUT "https://$CUSTOM-DOMAIN/v3alpha/user_schemas/$SCHEMA_ID" \
curl -X PUT "https://${CUSTOM_DOMAIN}/v3alpha/user_schemas/$SCHEMA_ID" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H "Authorization: Bearer $ACCESS_TOKEN" \
@@ -141,7 +141,7 @@ In this case we will query for the one with state `active`. Check out the api do
The API also allows retrieving a single [schema by ID](/apis/resources/user_schema_service_v3/user-schema-service-get-user-schema-by-id).
```bash
curl -X POST "https://$CUSTOM-DOMAIN/v3alpha/user_schemas/search" \
curl -X POST "https://${CUSTOM_DOMAIN}/v3alpha/user_schemas/search" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H "Authorization: Bearer $ACCESS_TOKEN" \
docs/docs/guides/migrate/sources/auth0.md
+1 -1
View File
@@ -144,7 +144,7 @@ There are two recommended authentication methods:
#### Example cURL request
```bash
curl --location 'https://<instance-domain>/admin/v1/import' \
curl --location 'https://${CUSTOM_DOMAIN}/admin/v1/import' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer <access-token>' \
docs/docs/guides/migrate/sources/keycloak.md
+2 -2
View File
@@ -128,7 +128,7 @@ Use your **access token** or **PAT** to authenticate, then call the [Management
```bash
curl --request POST \
--url https://<instance-domain>/admin/v1/import \
--url https://${CUSTOM_DOMAIN}/admin/v1/import \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <token>' \
--data @importBody.json
@@ -197,7 +197,7 @@ You can verify that users were imported successfully by querying the **events AP
Use the following request:
```bash
curl --location 'https://<instance-domain>/admin/v1/events/_search' \
curl --location 'https://${CUSTOM_DOMAIN}/admin/v1/events/_search' \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '{
docs/docs/guides/solution-scenarios/b2c.mdx
+2 -2
View File
@@ -18,10 +18,10 @@ Creation can be done from [ZITADEL Console](https://${CUSTOM_DOMAIN}.zitadel.clo
Depending on your Software Development Life Cycle (SDLC) you can create multiple organizations or projects to keep your applications environments separated.
### Custom domain
### Organization Domain
Right after org creation you'll be greeted with the domain section of your organization.
ZITADEL automatically creates a custom domain of the form `[orgname].zitadel.cloud`, but you can create your own. Depending on the settings on the [Domain Policy](../../concepts/structure/policies) it has to be verified by saving a verification file on the specified location.
ZITADEL automatically creates an organization domain of the form `[orgname].zitadel.cloud`, but you can create your own. Depending on the settings on the [Domain Policy](../../concepts/structure/policies) it has to be verified by saving a verification file on the specified location.
We recommend that you create your domains early as they create a sense of confidence and trust for your application and changes later on might create additional migration effort.
You can read more about how ZITADEL handles usernames [here](../manage/console/organizations#how-zitadel-handles-usernames).
docs/docs/guides/solution-scenarios/domain-discovery.mdx
+3 -3
View File
@@ -11,7 +11,7 @@ Domain discovery is typically used in [B2B](./b2b) or [SaaS](./saas) scenarios w
![Overview Domain Discovery](/img/guides/solution-scenarios/domain-discovery.png)
In the example there is a service provider with a ZITADEL instance running on a [custom domain](/docs/guides/manage/cloud/instances#add-custom-domain) on `login.mycompany.com`.
In the example there is a service provider with a ZITADEL instance running on a [Custom Domain](/docs/guides/manage/cloud/instances#add-custom-domain) on `login.mycompany.com`.
By default all users login on the organization **CIAM** with their preferred social login provider.
Users of the two business customers **Alpha** and **Beta** should login according to their organization login and access policy settings.
@@ -51,7 +51,7 @@ Follow this [configuration guide](/docs/guides/solution-scenarios/configurations
### Other considerations
You can also have multiple custom domains pointing to the same instance as described in this [configuration guide](/docs/guides/solution-scenarios/configurations#custom-application-domain-per-organization). In our example you could also use `alpha.mycompany.com` to show the login page of your instance.
You can also have multiple Custom Domains pointing to the same instance as described in this [configuration guide](/docs/guides/solution-scenarios/configurations#custom-application-domain-per-organization). In our example you could also use `alpha.mycompany.com` to show the login page of your instance.
The domain of your email notification can be changed by [setting up your SMTP](/docs/guides/manage/console/default-settings#smtp).
@@ -104,7 +104,7 @@ You should be all setup to try out domain discovery.
The user journeys for the different users would look as follows:
- User (Alice, Bob, Chuck) clicks a login button in your application
- Redirected to `login.mycompany.com` (ZITADEL running under a custom domain)
- Redirected to `login.mycompany.com` (ZITADEL running under a Custom Domain)
Chuck
docs/docs/guides/solution-scenarios/restrict-console.mdx
+5 -5
View File
@@ -57,10 +57,10 @@ More detailed information about creating a PAT and manager roles you can find [h
Then you have to send the following request:
```bash
curl -L -X PUT "https://${CUSTOM_DOMAIN}/management/v1/projects/$PROJECT_ID" \
curl -L -X PUT "https://${CUSTOM_DOMAIN}/management/v1/projects/${PROJECT_ID}" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H "Authorization: Bearer $PAT" \
-H "Authorization: Bearer ${PAT}" \
--data-raw '{
"name": "ZITADEL",
"projectRoleAssertion": false,
@@ -71,9 +71,9 @@ curl -L -X PUT "https://${CUSTOM_DOMAIN}/management/v1/projects/$PROJECT_ID" \
```
Where
- CUSTOM_DOMAIN is your domain, f.e. mydemo.zitadel.cloud
- PAT is your service user's personal access token
- PROJECT_ID is the default-project's ID that can be found in Console, see screenshot above
- `${CUSTOM_DOMAIN}` is your Custom Domain, f.e. mydemo.zitadel.cloud
- `${PAT}` is your service user's personal access token
- `${PROJECT_ID}` is the default-project's ID that can be found in Console, see screenshot above
You should now be able to login with users of organization that have the grant (in this example users of the organization "Customer-A").
All other users should see the following error message after authentication:
docs/docs/self-hosting/deploy/troubleshooting/_instance_not_found.mdx
+2 -2
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`.
You can find further instructions in our guide about [custom domains](/docs/self-hosting/manage/custom-domain).
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](/docs/self-hosting/manage/custom-domain).
We also provide a guide on how to [configure](/docs/self-hosting/manage/configure) ZITADEL with variables from files or environment variables.
docs/docs/self-hosting/manage/cache.md
+1 -1
View File
@@ -161,7 +161,7 @@ Caches:
All HTTP and gRPC requests sent to ZITADEL receive an instance context. The instance is usually resolved by the domain from the request. In some cases, like the [system service](/docs/apis/resources/system/system-service), the instance can be resolved by its ID. An instance object contains many of the [default settings](/docs/guides/manage/console/default-settings):
- Instance [features](/docs/guides/manage/console/default-settings#features)
- Custom domains: generated and [custom](/docs/guides/manage/cloud/instances#add-custom-domain)
- Custom Domains: generated and [custom](/docs/guides/manage/cloud/instances#add-custom-domain)
- [Trusted domains](/docs/apis/resources/admin/admin-service-add-instance-trusted-domain)
- Security settings ([IFrame policy](/docs/guides/solution-scenarios/configurations#embedding-zitadel-in-an-iframe))
- Limits[^2]
docs/docs/self-hosting/manage/custom-domain.md
+1 -1
View File
@@ -23,7 +23,7 @@ ExternalPort: 8080
ExternalSecure: false
```
For productive setups however, we recommend using HTTPS and a custom domain:
For productive setups however, we recommend using HTTPS and a Custom Domain:
```yaml
ExternalDomain: 'zitadel.my.domain'
docs/docs/support/troubleshooting.mdx
+1 -1
View File
@@ -70,7 +70,7 @@ Instead of `urn:zitadel:iam:org:project:id:zitadel:aud` you could also use `urn:
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.
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/).
docs/sidebars.js
+1 -1
View File
@@ -1094,7 +1094,7 @@ module.exports = {
title: "Instance Service API",
slug: "/apis/resources/instance_service_v2",
description:
"This API is intended to manage instances, custom domains and trusted domains in ZITADEL.\n" +
"This API is intended to manage instances, Custom Domains and trusted domains in ZITADEL.\n" +
"\n" +
"This v2 of the API provides the same functionalities as the v1, but organised on a per resource basis.\n" +
"The whole functionality related to domains (custom and trusted) has been moved under this instance API."
docs/src/components/environment.jsx
+1 -1
View File
@@ -39,7 +39,7 @@ export function SetEnvironment() {
return (
<div>
<div className={styles.inputwrapper}>
<label className={styles.label}>Your custom domain</label>
<label className={styles.label}>Your Custom Domain</label>
<input
className={styles.input}
id="instance"
internal/static/i18n/en.yaml
+1 -1
View File
@@ -70,7 +70,7 @@ Errors:
NotFound: SMTP configuration not found
AlreadyExists: SMTP configuration already exists
AlreadyDeactivated: SMTP configuration already deactivated
SenderAdressNotCustomDomain: The sender address must be configured as custom domain on the instance.
SenderAdressNotCustomDomain: The sender address must be configured as Custom Domain on the instance.
TestEmailNotFound: Email address for test not found
Notification:
NoDomain: No Domain found for message
proto/zitadel/action/v2/action_service.proto
+3 -3
View File
@@ -46,7 +46,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -59,8 +59,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/action/v2beta/action_service.proto
+3 -3
View File
@@ -46,7 +46,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -59,8 +59,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/admin.proto
+3 -3
View File
@@ -134,7 +134,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/admin/v1";
external_docs: {
@@ -154,8 +154,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/analytics/v2beta/telemetry.proto
+1 -1
View File
@@ -10,7 +10,7 @@ option go_package = "github.com/zitadel/zitadel/pkg/grpc/analytics/v2beta;analyt
message InstanceInformation {
// The unique identifier of the instance.
string id = 1;
// The custom domains (incl. generated ones) of the instance.
// The Custom Domains (incl. generated ones) of the instance.
repeated string domains = 2;
// The creation date of the instance.
google.protobuf.Timestamp created_at = 3;
proto/zitadel/app/v2beta/app_service.proto
+3 -3
View File
@@ -45,7 +45,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -58,8 +58,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/auth.proto
+3 -3
View File
@@ -80,7 +80,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
produces: "application/grpc";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/auth/v1";
external_docs: {
@@ -100,8 +100,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/feature/v2/feature_service.proto
+3 -3
View File
@@ -40,7 +40,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -53,8 +53,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/feature/v2beta/feature_service.proto
+3 -3
View File
@@ -40,7 +40,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -53,8 +53,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/group/v2/group_service.proto
+3 -3
View File
@@ -43,7 +43,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -56,8 +56,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/idp/v2/idp_service.proto
+3 -3
View File
@@ -39,7 +39,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -52,8 +52,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/instance/v2/instance.proto
+2 -2
View File
@@ -113,7 +113,7 @@ message Filter {
// Filter for one or more specific instance IDs.
zitadel.filter.v2.InIDsFilter in_ids_filter = 1;
// Filter for instances that have at least one of the specified custom domains.
// Filter for instances that have at least one of the specified Custom Domains.
CustomDomainsFilter custom_domains_filter = 2;
}
}
@@ -134,7 +134,7 @@ message CustomDomainFilter {
oneof filter {
option (validate.required) = true;
// Filter for a specific custom domain.
// Filter for a specific Custom Domain.
DomainFilter domain_filter = 1;
// Filter whether the domain is auto-generated.
proto/zitadel/instance/v2/instance_service.proto
+10 -10
View File
@@ -94,8 +94,8 @@ service InstanceService {
// Add Custom Domain
//
// Adds a custom domain to the instance.
// The custom domain must be unique across all instances.
// Adds a Custom Domain to the instance.
// The Custom Domain must be unique across all instances.
// Once the domain is added, it will be used to route requests to this instance.
// This method requires system level permissions and cannot be called from an instance context.
//
@@ -111,7 +111,7 @@ service InstanceService {
// Remove Custom Domain
//
// Removes a custom domain from the instance.
// Removes a Custom Domain from the instance.
// Be aware that this will stop routing requests from this domain to the instance and
// might break existing setups or integrations.
// This method requires system level permissions and cannot be called from an instance context.
@@ -128,7 +128,7 @@ service InstanceService {
// List Custom Domains
//
// Lists custom domains of the instance.
// Lists Custom Domains of the instance.
//
// By default the instance will be determined by the context of the request,
// e.g. the host header.
@@ -158,8 +158,8 @@ service InstanceService {
// Once the domain is added, it can be used in API responses like OIDC discovery,
// email templates, and more.
// This can be used in cases where the API is accessed through a different domain
// than the instance domain, e.g. proxy setups and custom login UIs.
// Unlike custom domain, trusted domains are not used to route requests to this instance
// than the Custom Domain, e.g. proxy setups and custom login UIs.
// Unlike Custom Domain, trusted domains are not used to route requests to this instance
// and therefore do not need to be uniquely assigned to an instance.
//
// Required permissions:
@@ -320,7 +320,7 @@ message AddCustomDomainRequest {
(google.api.field_behavior) = REQUIRED
];
// Custom domain to add to the instance.
// Custom Domain to add to the instance.
// Must be a valid domain name.
// Once the domain is added, it will be used to route requests to this instance.
string custom_domain = 2 [
@@ -397,7 +397,7 @@ message ListCustomDomainsRequest {
}
message ListCustomDomainsResponse {
// The list of custom domains matching the query.
// The list of Custom Domains matching the query.
repeated CustomDomain domains = 1;
// Contains the total number of domains matching the query and the applied limit.
@@ -421,8 +421,8 @@ message AddTrustedDomainRequest {
// Once the domain is added, it can be used in API responses like OIDC discovery,
// email templates, and more.
// This can be used in cases where the API is accessed through a different domain
// than the instance domain, e.g. proxy setups and custom login UIs.
// Unlike custom domains, trusted domains are not used to route requests to this instance
// than the Custom Domain, e.g. proxy setups and custom login UIs.
// Unlike Custom Domains, trusted domains are not used to route requests to this instance
// and therefore do not need to be uniquely assigned to an instance.
string trusted_domain = 2 [
(validate.rules).string = {min_len: 1, max_len: 253},
proto/zitadel/instance/v2beta/instance_service.proto
+9 -9
View File
@@ -42,7 +42,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -55,8 +55,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
@@ -241,7 +241,7 @@ service InstanceService {
//
// Deprecated: please move to the corresponding endpoint under instance service v2. This endpoint will be removed with the next major version of ZITADEL.
//
// Adds a custom domain to the instance in context.
// Adds a Custom Domain to the instance in context.
//
// The instance_id in the input message will be used in the future
//
@@ -253,7 +253,7 @@ service InstanceService {
responses: {
key: "200";
value: {
description: "The added custom domain.";
description: "The added Custom Domain.";
}
};
};
@@ -274,7 +274,7 @@ service InstanceService {
//
// Deprecated: please move to the corresponding endpoint under instance service v2. This endpoint will be removed with the next major version of ZITADEL.
//
// Removes a custom domain from the instance.
// Removes a Custom Domain from the instance.
//
// The instance_id in the input message will be used in the future.
//
@@ -286,7 +286,7 @@ service InstanceService {
responses: {
key: "200";
value: {
description: "The removed custom domain.";
description: "The removed Custom Domain.";
}
};
};
@@ -306,7 +306,7 @@ service InstanceService {
//
// Deprecated: please move to the corresponding endpoint under instance service v2. This endpoint will be removed with the next major version of ZITADEL.
//
// Lists custom domains of the instance.
// Lists Custom Domains of the instance.
//
// The instance_id in the input message will be used in the future.
//
@@ -318,7 +318,7 @@ service InstanceService {
responses: {
key: "200";
value: {
description: "The list of custom domains.";
description: "The list of Custom Domains.";
}
};
};
proto/zitadel/internal_permission/v2beta/internal_permission_service.proto
+3 -3
View File
@@ -44,7 +44,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -57,8 +57,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/management.proto
+4 -4
View File
@@ -146,7 +146,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/management/v1";
external_docs: {
@@ -166,8 +166,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
@@ -193,7 +193,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
extensions: {
key: "x-zitadel-orgid";
value: {
string_value: "$YOUR-ORGANIZATION";
string_value: "$YOUR_ORGANIZATION";
}
}
};
proto/zitadel/oidc/v2/oidc_service.proto
+3 -3
View File
@@ -39,7 +39,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -52,8 +52,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/oidc/v2beta/oidc_service.proto
+3 -3
View File
@@ -39,7 +39,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -52,8 +52,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/org/v2/org_service.proto
+4 -4
View File
@@ -52,7 +52,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -65,8 +65,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
@@ -615,7 +615,7 @@ message UpdateOrganizationRequest {
// changing the name will also change the domain.
// Additionally, if the domain is used as suffix for user logins,
// their login names will also change accordingly.
// It will not affect any custom domains added to the organization.
// It will not affect any organization domains added to the organization.
string name = 2 [
(validate.rules).string = {min_len: 1, max_len: 200},
(google.api.field_behavior) = REQUIRED,
proto/zitadel/org/v2beta/org_service.proto
+3 -3
View File
@@ -46,7 +46,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -59,8 +59,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/project/v2beta/project_service.proto
+3 -3
View File
@@ -44,7 +44,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -57,8 +57,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/resources/debug_events/v3alpha/debug_events_service.proto
+3 -3
View File
@@ -42,7 +42,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/resources/v3alpha/debug";
external_docs: {
@@ -55,8 +55,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/resources/user/v3alpha/user_service.proto
+3 -3
View File
@@ -45,7 +45,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -58,8 +58,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/resources/userschema/v3alpha/user_schema_service.proto
+3 -3
View File
@@ -42,7 +42,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -55,8 +55,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/saml/v2/saml_service.proto
+3 -3
View File
@@ -39,7 +39,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -52,8 +52,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/session/v2/session_service.proto
+3 -3
View File
@@ -43,7 +43,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -56,8 +56,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/session/v2beta/session_service.proto
+3 -3
View File
@@ -43,7 +43,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -56,8 +56,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/settings/v2/domain_settings.proto
+1 -1
View File
@@ -16,7 +16,7 @@ message DomainSettings {
// If disabled, organization domains will be created as already verified automatically.
bool require_org_domain_verification = 2;
// If enabled, the SMTP sender address domain must match custom domain on the instance.
// If enabled, the SMTP sender address domain must match Custom Domain on the instance.
bool smtp_sender_address_matches_instance_domain = 3;
// ResourceOwnerType returns if the setting is managed on the organization explicitly or
proto/zitadel/settings/v2/settings_service.proto
+3 -3
View File
@@ -50,7 +50,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -63,8 +63,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";
proto/zitadel/settings/v2beta/settings_service.proto
+3 -3
View File
@@ -48,7 +48,7 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
consumes: "application/grpc-web+proto";
produces: "application/grpc-web+proto";
host: "$CUSTOM-DOMAIN";
host: "$CUSTOM_DOMAIN";
base_path: "/";
external_docs: {
@@ -61,8 +61,8 @@ option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
value: {
type: TYPE_OAUTH2;
flow: FLOW_ACCESS_CODE;
authorization_url: "$CUSTOM-DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM-DOMAIN/oauth/v2/token";
authorization_url: "$CUSTOM_DOMAIN/oauth/v2/authorize";
token_url: "$CUSTOM_DOMAIN/oauth/v2/token";
scopes: {
scope: {
key: "openid";

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