From 8c0d6c68177f69970a746290400ffafe358f11b1 Mon Sep 17 00:00:00 2001 From: Livio Spring Date: Tue, 20 Jan 2026 05:56:57 +0100 Subject: [PATCH] chore: naming custom domain (#11383) # 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 --- docs/base.yaml | 2 +- docs/docs/apis/introduction.mdx | 4 +-- docs/docs/apis/openidoauth/authn-methods.md | 4 +-- docs/docs/apis/openidoauth/claims.md | 4 +-- docs/docs/apis/openidoauth/grant-types.md | 4 +-- docs/docs/apis/saml/endpoints.md | 28 +++++++++---------- docs/docs/concepts/features/audit-trail.md | 2 +- docs/docs/concepts/features/console.md | 2 +- docs/docs/concepts/features/custom-domain.md | 12 ++++---- docs/docs/concepts/features/passkeys.md | 2 +- docs/docs/concepts/features/selfservice.md | 2 +- .../concepts/structure/_org_description.mdx | 2 +- docs/docs/concepts/structure/instance.mdx | 2 +- .../examples/identity-proxy/oauth2-proxy.md | 2 +- docs/docs/examples/login/go.md | 4 +-- docs/docs/examples/login/java-spring.md | 2 +- docs/docs/examples/login/nextjs-b2b.md | 26 ++++++++--------- docs/docs/examples/login/symfony.md | 2 +- docs/docs/examples/secure-api/go.md | 4 +-- docs/docs/examples/secure-api/java-spring.md | 2 +- .../guides/integrate/actions/testing-event.md | 6 ++-- .../actions/testing-function-manipulation.md | 4 +-- .../integrate/actions/testing-function.md | 4 +-- .../actions/testing-request-manipulation.md | 8 +++--- .../actions/testing-request-signature.mdx | 10 +++---- .../integrate/actions/testing-request.md | 6 ++-- .../actions/testing-response-manipulation.md | 4 +-- .../integrate/actions/testing-response.md | 6 ++-- .../integrate/actions/webhook-site-setup.md | 6 ++-- .../integrate/authenticated-mongodb-charts.md | 2 +- .../guides/integrate/back-channel-logout.mdx | 2 +- .../integrate/identity-providers/apple.mdx | 2 +- .../integrate/identity-providers/jwt_idp.md | 4 +-- .../identity-providers/linkedin_oauth.mdx | 2 +- .../guides/integrate/login/hosted-login.mdx | 4 +-- .../guides/integrate/login/oidc/logout.md | 2 +- .../guides/integrate/login/oidc/webkeys.md | 14 +++++----- docs/docs/guides/integrate/onboarding/b2b.mdx | 2 +- .../service-users/client-credentials.md | 4 +-- .../service-users/personal-access-token.md | 2 +- .../service-users/private-key-jwt.md | 4 +-- .../guides/integrate/services/aws-saml.md | 2 +- .../guides/integrate/services/gitlab-saml.md | 2 +- .../integrate/services/google-workspace.md | 24 ++++++++-------- docs/docs/guides/integrate/token-exchange.mdx | 4 +-- .../token-introspection/private-key-jwt.mdx | 28 +++++++++---------- .../zitadel-apis/_accessing_zitadel_api.md | 6 ++-- .../zitadel-apis/access-zitadel-apis.md | 10 +++---- .../zitadel-apis/access-zitadel-system-api.md | 4 +-- .../integrate/zitadel-apis/event-api.md | 14 +++++----- .../example-zitadel-api-with-go.md | 2 +- docs/docs/guides/manage/cloud/instances.md | 16 +++++------ .../manage/console/console-overview.mdx | 2 +- .../manage/console/default-settings.mdx | 6 ++-- .../guides/manage/console/organizations.mdx | 2 +- docs/docs/guides/manage/console/overview.mdx | 2 +- .../customize/notification-providers.mdx | 8 +++--- .../guides/manage/customize/user-metadata.md | 14 +++++----- .../guides/manage/customize/user-schema.md | 6 ++-- docs/docs/guides/migrate/sources/auth0.md | 2 +- docs/docs/guides/migrate/sources/keycloak.md | 4 +-- docs/docs/guides/solution-scenarios/b2c.mdx | 4 +-- .../solution-scenarios/domain-discovery.mdx | 6 ++-- .../solution-scenarios/restrict-console.mdx | 10 +++---- .../troubleshooting/_instance_not_found.mdx | 4 +-- docs/docs/self-hosting/manage/cache.md | 2 +- .../docs/self-hosting/manage/custom-domain.md | 2 +- docs/docs/support/troubleshooting.mdx | 2 +- docs/sidebars.js | 2 +- docs/src/components/environment.jsx | 2 +- internal/static/i18n/en.yaml | 2 +- proto/zitadel/action/v2/action_service.proto | 6 ++-- .../action/v2beta/action_service.proto | 6 ++-- proto/zitadel/admin.proto | 6 ++-- .../zitadel/analytics/v2beta/telemetry.proto | 2 +- proto/zitadel/app/v2beta/app_service.proto | 6 ++-- proto/zitadel/auth.proto | 6 ++-- .../zitadel/feature/v2/feature_service.proto | 6 ++-- .../feature/v2beta/feature_service.proto | 6 ++-- proto/zitadel/group/v2/group_service.proto | 6 ++-- proto/zitadel/idp/v2/idp_service.proto | 6 ++-- proto/zitadel/instance/v2/instance.proto | 4 +-- .../instance/v2/instance_service.proto | 20 ++++++------- .../instance/v2beta/instance_service.proto | 18 ++++++------ .../v2beta/internal_permission_service.proto | 6 ++-- proto/zitadel/management.proto | 8 +++--- proto/zitadel/oidc/v2/oidc_service.proto | 6 ++-- proto/zitadel/oidc/v2beta/oidc_service.proto | 6 ++-- proto/zitadel/org/v2/org_service.proto | 8 +++--- proto/zitadel/org/v2beta/org_service.proto | 6 ++-- .../project/v2beta/project_service.proto | 6 ++-- .../v3alpha/debug_events_service.proto | 6 ++-- .../resources/user/v3alpha/user_service.proto | 6 ++-- .../v3alpha/user_schema_service.proto | 6 ++-- proto/zitadel/saml/v2/saml_service.proto | 6 ++-- .../zitadel/session/v2/session_service.proto | 6 ++-- .../session/v2beta/session_service.proto | 6 ++-- .../zitadel/settings/v2/domain_settings.proto | 2 +- .../settings/v2/settings_service.proto | 6 ++-- .../settings/v2beta/settings_service.proto | 6 ++-- proto/zitadel/system.proto | 8 +++--- proto/zitadel/user/v2/user_service.proto | 6 ++-- proto/zitadel/user/v2beta/user_service.proto | 6 ++-- proto/zitadel/webkey/v2/webkey_service.proto | 6 ++-- .../webkey/v2beta/webkey_service.proto | 6 ++-- 105 files changed, 315 insertions(+), 315 deletions(-) diff --git a/docs/base.yaml b/docs/base.yaml index 62aacca24..2c640a7a3 100644 --- a/docs/base.yaml +++ b/docs/base.yaml @@ -2,4 +2,4 @@ openapi: 3.1.0 info: version: v2 servers: - - url: https://$CUSTOM-DOMAIN \ No newline at end of file + - url: https://$CUSTOM_DOMAIN \ No newline at end of file diff --git a/docs/docs/apis/introduction.mdx b/docs/docs/apis/introduction.mdx index e457f1374..f47e56f5e 100644 --- a/docs/docs/apis/introduction.mdx +++ b/docs/docs/apis/introduction.mdx @@ -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 diff --git a/docs/docs/apis/openidoauth/authn-methods.md b/docs/docs/apis/openidoauth/authn-methods.md index 7e9566fd0..d4086ad69 100644 --- a/docs/docs/apis/openidoauth/authn-methods.md +++ b/docs/docs/apis/openidoauth/authn-methods.md @@ -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 } diff --git a/docs/docs/apis/openidoauth/claims.md b/docs/docs/apis/openidoauth/claims.md index 5c002e7b6..e33c66698 100644 --- a/docs/docs/apis/openidoauth/claims.md +++ b/docs/docs/apis/openidoauth/claims.md @@ -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)
`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 | diff --git a/docs/docs/apis/openidoauth/grant-types.md b/docs/docs/apis/openidoauth/grant-types.md index 57537f353..4aac955d0 100644 --- a/docs/docs/apis/openidoauth/grant-types.md +++ b/docs/docs/apis/openidoauth/grant-types.md @@ -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 } diff --git a/docs/docs/apis/saml/endpoints.md b/docs/docs/apis/saml/endpoints.md index 9d3be22e5..22f9d6be9 100644 --- a/docs/docs/apis/saml/endpoints.md +++ b/docs/docs/apis/saml/endpoints.md @@ -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 diff --git a/docs/docs/concepts/features/audit-trail.md b/docs/docs/concepts/features/audit-trail.md index 4ffd47619..7e7fc104f 100644 --- a/docs/docs/concepts/features/audit-trail.md +++ b/docs/docs/concepts/features/audit-trail.md @@ -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) diff --git a/docs/docs/concepts/features/console.md b/docs/docs/concepts/features/console.md index 1ae7dd17e..725049a2f 100644 --- a/docs/docs/concepts/features/console.md +++ b/docs/docs/concepts/features/console.md @@ -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: diff --git a/docs/docs/concepts/features/custom-domain.md b/docs/docs/concepts/features/custom-domain.md index ffae59ffb..b6bbe63f2 100644 --- a/docs/docs/concepts/features/custom-domain.md +++ b/docs/docs/concepts/features/custom-domain.md @@ -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). diff --git a/docs/docs/concepts/features/passkeys.md b/docs/docs/concepts/features/passkeys.md index 79cc3059b..54d2d52e3 100644 --- a/docs/docs/concepts/features/passkeys.md +++ b/docs/docs/concepts/features/passkeys.md @@ -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! \ No newline at end of file diff --git a/docs/docs/concepts/features/selfservice.md b/docs/docs/concepts/features/selfservice.md index aaf904f68..c93aa695f 100644 --- a/docs/docs/concepts/features/selfservice.md +++ b/docs/docs/concepts/features/selfservice.md @@ -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 diff --git a/docs/docs/concepts/structure/_org_description.mdx b/docs/docs/concepts/structure/_org_description.mdx index e25e254e1..a943f7bff 100644 --- a/docs/docs/concepts/structure/_org_description.mdx +++ b/docs/docs/concepts/structure/_org_description.mdx @@ -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}`). diff --git a/docs/docs/concepts/structure/instance.mdx b/docs/docs/concepts/structure/instance.mdx index 2e833a6d2..960db72c4 100644 --- a/docs/docs/concepts/structure/instance.mdx +++ b/docs/docs/concepts/structure/instance.mdx @@ -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. diff --git a/docs/docs/examples/identity-proxy/oauth2-proxy.md b/docs/docs/examples/identity-proxy/oauth2-proxy.md index a114a2793..5bf415c8b 100644 --- a/docs/docs/examples/identity-proxy/oauth2-proxy.md +++ b/docs/docs/examples/identity-proxy/oauth2-proxy.md @@ -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" ] diff --git a/docs/docs/examples/login/go.md b/docs/docs/examples/login/go.md index 658380017..9281905c3 100644 --- a/docs/docs/examples/login/go.md +++ b/docs/docs/examples/login/go.md @@ -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 --key -- clientID --redirectURI +go run main.go --domain --key -- clientID --redirectURI ``` This could look like: diff --git a/docs/docs/examples/login/java-spring.md b/docs/docs/examples/login/java-spring.md index f6bf42e1b..1841802fa 100644 --- a/docs/docs/examples/login/java-spring.md +++ b/docs/docs/examples/login/java-spring.md @@ -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 \ diff --git a/docs/docs/examples/login/nextjs-b2b.md b/docs/docs/examples/login/nextjs-b2b.md index 82697a87e..7623ffc45 100644 --- a/docs/docs/examples/login/nextjs-b2b.md +++ b/docs/docs/examples/login/nextjs-b2b.md @@ -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 diff --git a/docs/docs/examples/login/symfony.md b/docs/docs/examples/login/symfony.md index 0859fdb57..b07acf44c 100644 --- a/docs/docs/examples/login/symfony.md +++ b/docs/docs/examples/login/symfony.md @@ -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: diff --git a/docs/docs/examples/secure-api/go.md b/docs/docs/examples/secure-api/go.md index 66d1f2d07..ef0a7fa9c 100644 --- a/docs/docs/examples/secure-api/go.md +++ b/docs/docs/examples/secure-api/go.md @@ -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 --key +go run main.go --domain --key ``` This could look like: diff --git a/docs/docs/examples/secure-api/java-spring.md b/docs/docs/examples/secure-api/java-spring.md index 035d749a0..1f4ddc778 100644 --- a/docs/docs/examples/secure-api/java-spring.md +++ b/docs/docs/examples/secure-api/java-spring.md @@ -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 \ diff --git a/docs/docs/guides/integrate/actions/testing-event.md b/docs/docs/guides/integrate/actions/testing-event.md index c2325dbb2..d9adcb1a7 100644 --- a/docs/docs/guides/integrate/actions/testing-event.md +++ b/docs/docs/guides/integrate/actions/testing-event.md @@ -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 ' \ @@ -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 ' \ @@ -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 ' \ diff --git a/docs/docs/guides/integrate/actions/testing-function-manipulation.md b/docs/docs/guides/integrate/actions/testing-function-manipulation.md index 10d3b71ab..a73814038 100644 --- a/docs/docs/guides/integrate/actions/testing-function-manipulation.md +++ b/docs/docs/guides/integrate/actions/testing-function-manipulation.md @@ -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 ' \ @@ -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 ' \ diff --git a/docs/docs/guides/integrate/actions/testing-function.md b/docs/docs/guides/integrate/actions/testing-function.md index 4e1f6d64d..436dc3a35 100644 --- a/docs/docs/guides/integrate/actions/testing-function.md +++ b/docs/docs/guides/integrate/actions/testing-function.md @@ -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 ' \ @@ -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 ' \ diff --git a/docs/docs/guides/integrate/actions/testing-request-manipulation.md b/docs/docs/guides/integrate/actions/testing-request-manipulation.md index de00d5244..11ef81cc0 100644 --- a/docs/docs/guides/integrate/actions/testing-request-manipulation.md +++ b/docs/docs/guides/integrate/actions/testing-request-manipulation.md @@ -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 ' \ @@ -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 ' \ @@ -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 ' \ @@ -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 ' \ diff --git a/docs/docs/guides/integrate/actions/testing-request-signature.mdx b/docs/docs/guides/integrate/actions/testing-request-signature.mdx index 75faff178..88abee304 100644 --- a/docs/docs/guides/integrate/actions/testing-request-signature.mdx +++ b/docs/docs/guides/integrate/actions/testing-request-signature.mdx @@ -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 ' \ @@ -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 `` 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//publickeys' \ +curl -L -X POST 'https://${CUSTOM_DOMAIN}/v2/actions/targets//publickeys' \ -H 'Content-Type: application/json' \ -H 'Accept: application/json' \ -H 'Authorization: Bearer ' \ @@ -96,7 +96,7 @@ curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/actions/targets//publickeys Be sure to also activate the public key for the target using the returned `` from the previous request: ```shell -curl -L -X PUT 'https://$CUSTOM-DOMAIN/v2/actions/targets//publickeys//activate' \ +curl -L -X PUT 'https://${CUSTOM_DOMAIN}/v2/actions/targets//publickeys//activate' \ -H 'Content-Type: application/json' \ -H 'Accept: application/json' \ -H 'Authorization: Bearer ' @@ -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 ' \ @@ -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 ' \ diff --git a/docs/docs/guides/integrate/actions/testing-request.md b/docs/docs/guides/integrate/actions/testing-request.md index d2cee4f5f..e445593f7 100644 --- a/docs/docs/guides/integrate/actions/testing-request.md +++ b/docs/docs/guides/integrate/actions/testing-request.md @@ -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 ' \ @@ -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 ' \ @@ -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 ' \ diff --git a/docs/docs/guides/integrate/actions/testing-response-manipulation.md b/docs/docs/guides/integrate/actions/testing-response-manipulation.md index bb7cd2ee3..f56759e66 100644 --- a/docs/docs/guides/integrate/actions/testing-response-manipulation.md +++ b/docs/docs/guides/integrate/actions/testing-response-manipulation.md @@ -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 ' \ @@ -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 ' \ diff --git a/docs/docs/guides/integrate/actions/testing-response.md b/docs/docs/guides/integrate/actions/testing-response.md index ed3fa1135..9fdf1983f 100644 --- a/docs/docs/guides/integrate/actions/testing-response.md +++ b/docs/docs/guides/integrate/actions/testing-response.md @@ -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 ' \ @@ -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 ' \ @@ -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 ' \ diff --git a/docs/docs/guides/integrate/actions/webhook-site-setup.md b/docs/docs/guides/integrate/actions/webhook-site-setup.md index 05098e875..658093367 100644 --- a/docs/docs/guides/integrate/actions/webhook-site-setup.md +++ b/docs/docs/guides/integrate/actions/webhook-site-setup.md @@ -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 ' \ @@ -117,7 +117,7 @@ See [Set an execution](/apis/resources/action_service_v2/action-service-set-exec Here, `` 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 ' \ @@ -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 ' \ diff --git a/docs/docs/guides/integrate/authenticated-mongodb-charts.md b/docs/docs/guides/integrate/authenticated-mongodb-charts.md index ed6a72bca..6f7eadef6 100644 --- a/docs/docs/guides/integrate/authenticated-mongodb-charts.md +++ b/docs/docs/guides/integrate/authenticated-mongodb-charts.md @@ -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: diff --git a/docs/docs/guides/integrate/back-channel-logout.mdx b/docs/docs/guides/integrate/back-channel-logout.mdx index 4c2bfb6c2..66eb4c2e9 100644 --- a/docs/docs/guides/integrate/back-channel-logout.mdx +++ b/docs/docs/guides/integrate/back-channel-logout.mdx @@ -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 | diff --git a/docs/docs/guides/integrate/identity-providers/apple.mdx b/docs/docs/guides/integrate/identity-providers/apple.mdx index fda68691c..572a6da28 100644 --- a/docs/docs/guides/integrate/identity-providers/apple.mdx +++ b/docs/docs/guides/integrate/identity-providers/apple.mdx @@ -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 diff --git a/docs/docs/guides/integrate/identity-providers/jwt_idp.md b/docs/docs/guides/integrate/identity-providers/jwt_idp.md index 372b0e464..7a6b384ba 100644 --- a/docs/docs/guides/integrate/identity-providers/jwt_idp.md +++ b/docs/docs/guides/integrate/identity-providers/jwt_idp.md @@ -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):** diff --git a/docs/docs/guides/integrate/identity-providers/linkedin_oauth.mdx b/docs/docs/guides/integrate/identity-providers/linkedin_oauth.mdx index edcc13a71..d215d8f3a 100644 --- a/docs/docs/guides/integrate/identity-providers/linkedin_oauth.mdx +++ b/docs/docs/guides/integrate/identity-providers/linkedin_oauth.mdx @@ -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 diff --git a/docs/docs/guides/integrate/login/hosted-login.mdx b/docs/docs/guides/integrate/login/hosted-login.mdx index bb97f6bba..c8b93d723 100644 --- a/docs/docs/guides/integrate/login/hosted-login.mdx +++ b/docs/docs/guides/integrate/login/hosted-login.mdx @@ -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:///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. diff --git a/docs/docs/guides/integrate/login/oidc/logout.md b/docs/docs/guides/integrate/login/oidc/logout.md index c5dd7142a..b81bfaf7a 100644 --- a/docs/docs/guides/integrate/login/oidc/logout.md +++ b/docs/docs/guides/integrate/login/oidc/logout.md @@ -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 diff --git a/docs/docs/guides/integrate/login/oidc/webkeys.md b/docs/docs/guides/integrate/login/oidc/webkeys.md index b85cf796f..3935368ff 100644 --- a/docs/docs/guides/integrate/login/oidc/webkeys.md +++ b/docs/docs/guides/integrate/login/oidc/webkeys.md @@ -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 ' \ @@ -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 ' \ @@ -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 ' \ @@ -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 ' \ @@ -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 ' -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 ' \ @@ -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 ' ``` diff --git a/docs/docs/guides/integrate/onboarding/b2b.mdx b/docs/docs/guides/integrate/onboarding/b2b.mdx index e1584218f..e0e4945b6 100644 --- a/docs/docs/guides/integrate/onboarding/b2b.mdx +++ b/docs/docs/guides/integrate/onboarding/b2b.mdx @@ -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 ' \ diff --git a/docs/docs/guides/integrate/service-users/client-credentials.md b/docs/docs/guides/integrate/service-users/client-credentials.md index 204119f1c..b3be8383a 100644 --- a/docs/docs/guides/integrate/service-users/client-credentials.md +++ b/docs/docs/guides/integrate/service-users/client-credentials.md @@ -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) diff --git a/docs/docs/guides/integrate/service-users/personal-access-token.md b/docs/docs/guides/integrate/service-users/personal-access-token.md index 2b42c89d0..120f9e6ed 100644 --- a/docs/docs/guides/integrate/service-users/personal-access-token.md +++ b/docs/docs/guides/integrate/service-users/personal-access-token.md @@ -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}' ``` diff --git a/docs/docs/guides/integrate/service-users/private-key-jwt.md b/docs/docs/guides/integrate/service-users/private-key-jwt.md index 7f84eeb23..5cf673dbc 100644 --- a/docs/docs/guides/integrate/service-users/private-key-jwt.md +++ b/docs/docs/guides/integrate/service-users/private-key-jwt.md @@ -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' \ diff --git a/docs/docs/guides/integrate/services/aws-saml.md b/docs/docs/guides/integrate/services/aws-saml.md index cd9c4a6ed..a68a041b3 100644 --- a/docs/docs/guides/integrate/services/aws-saml.md +++ b/docs/docs/guides/integrate/services/aws-saml.md @@ -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". diff --git a/docs/docs/guides/integrate/services/gitlab-saml.md b/docs/docs/guides/integrate/services/gitlab-saml.md index 52a0e77a1..945f658ec 100644 --- a/docs/docs/guides/integrate/services/gitlab-saml.md +++ b/docs/docs/guides/integrate/services/gitlab-saml.md @@ -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. diff --git a/docs/docs/guides/integrate/services/google-workspace.md b/docs/docs/guides/integrate/services/google-workspace.md index 18b3647e0..b6bad9764 100644 --- a/docs/docs/guides/integrate/services/google-workspace.md +++ b/docs/docs/guides/integrate/services/google-workspace.md @@ -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* diff --git a/docs/docs/guides/integrate/token-exchange.mdx b/docs/docs/guides/integrate/token-exchange.mdx index fcb58c20f..87807f9e1 100644 --- a/docs/docs/guides/integrate/token-exchange.mdx +++ b/docs/docs/guides/integrate/token-exchange.mdx @@ -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 ' \ @@ -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: diff --git a/docs/docs/guides/integrate/token-introspection/private-key-jwt.mdx b/docs/docs/guides/integrate/token-introspection/private-key-jwt.mdx index dbf7d706f..2bf36a4f3 100644 --- a/docs/docs/guides/integrate/token-introspection/private-key-jwt.mdx +++ b/docs/docs/guides/integrate/token-introspection/private-key-jwt.mdx @@ -82,10 +82,10 @@ To use Private Key JWT for introspection, you must register your client applicat ``` { "type": "application", - "keyId": "", - "key": "-----BEGIN RSA PRIVATE KEY-----\n\n-----END RSA PRIVATE KEY-----\n", - "appId": "", - "clientId": "" + "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": "" + "kid": "${YOUR_KEY_ID}" } ``` **Payload:** ```json { - "iss": "", - "sub": "", - "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... \ diff --git a/docs/docs/guides/integrate/zitadel-apis/_accessing_zitadel_api.md b/docs/docs/guides/integrate/zitadel-apis/_accessing_zitadel_api.md index cf74299ad..283527d31 100644 --- a/docs/docs/guides/integrate/zitadel-apis/_accessing_zitadel_api.md +++ b/docs/docs/guides/integrate/zitadel-apis/_accessing_zitadel_api.md @@ -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" ``` diff --git a/docs/docs/guides/integrate/zitadel-apis/access-zitadel-apis.md b/docs/docs/guides/integrate/zitadel-apis/access-zitadel-apis.md index 46c4ee71f..14fa3a5d8 100644 --- a/docs/docs/guides/integrate/zitadel-apis/access-zitadel-apis.md +++ b/docs/docs/guides/integrate/zitadel-apis/access-zitadel-apis.md @@ -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}' ``` diff --git a/docs/docs/guides/integrate/zitadel-apis/access-zitadel-system-api.md b/docs/docs/guides/integrate/zitadel-apis/access-zitadel-system-api.md index 770aec456..06c491608 100644 --- a/docs/docs/guides/integrate/zitadel-apis/access-zitadel-system-api.md +++ b/docs/docs/guides/integrate/zitadel-apis/access-zitadel-system-api.md @@ -89,7 +89,7 @@ The JWT payload will need to contain the following claims: { "iss": "", "sub": "", - "aud": "", + "aud": "", "exp": , "iat": } @@ -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' ``` diff --git a/docs/docs/guides/integrate/zitadel-apis/event-api.md b/docs/docs/guides/integrate/zitadel-apis/event-api.md index dbe8ac737..f055adffd 100644 --- a/docs/docs/guides/integrate/zitadel-apis/event-api.md +++ b/docs/docs/guides/integrate/zitadel-apis/event-api.md @@ -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 '{ diff --git a/docs/docs/guides/integrate/zitadel-apis/example-zitadel-api-with-go.md b/docs/docs/guides/integrate/zitadel-apis/example-zitadel-api-with-go.md index ef3f1739e..f16be7238 100644 --- a/docs/docs/guides/integrate/zitadel-apis/example-zitadel-api-with-go.md +++ b/docs/docs/guides/integrate/zitadel-apis/example-zitadel-api-with-go.md @@ -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 --key +go run cli.go --domain --key ``` This could look like: diff --git a/docs/docs/guides/manage/cloud/instances.md b/docs/docs/guides/manage/cloud/instances.md index 9fbc74052..3e5fde175 100644 --- a/docs/docs/guides/manage/cloud/instances.md +++ b/docs/docs/guides/manage/cloud/instances.md @@ -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 diff --git a/docs/docs/guides/manage/console/console-overview.mdx b/docs/docs/guides/manage/console/console-overview.mdx index 3f9ebd286..295c8bdc7 100644 --- a/docs/docs/guides/manage/console/console-overview.mdx +++ b/docs/docs/guides/manage/console/console-overview.mdx @@ -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 diff --git a/docs/docs/guides/manage/console/default-settings.mdx b/docs/docs/guides/manage/console/default-settings.mdx index 31560f187..83fea8140 100644 --- a/docs/docs/guides/manage/console/default-settings.mdx +++ b/docs/docs/guides/manage/console/default-settings.mdx @@ -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 diff --git a/docs/docs/guides/manage/console/organizations.mdx b/docs/docs/guides/manage/console/organizations.mdx index 03cc6a99a..0ca83ccd9 100644 --- a/docs/docs/guides/manage/console/organizations.mdx +++ b/docs/docs/guides/manage/console/organizations.mdx @@ -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. `' \ @@ -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 ' \ @@ -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 ' \ @@ -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 ' \ diff --git a/docs/docs/guides/manage/customize/user-metadata.md b/docs/docs/guides/manage/customize/user-metadata.md index 087956d39..a9dbd7c9e 100644 --- a/docs/docs/guides/manage/customize/user-metadata.md +++ b/docs/docs/guides/manage/customize/user-metadata.md @@ -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. diff --git a/docs/docs/guides/manage/customize/user-schema.md b/docs/docs/guides/manage/customize/user-schema.md index 8bf8c6b33..78fd4ea6a 100644 --- a/docs/docs/guides/manage/customize/user-schema.md +++ b/docs/docs/guides/manage/customize/user-schema.md @@ -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" \ diff --git a/docs/docs/guides/migrate/sources/auth0.md b/docs/docs/guides/migrate/sources/auth0.md index 09697f9cd..3d270892a 100644 --- a/docs/docs/guides/migrate/sources/auth0.md +++ b/docs/docs/guides/migrate/sources/auth0.md @@ -144,7 +144,7 @@ There are two recommended authentication methods: #### Example cURL request ```bash -curl --location 'https:///admin/v1/import' \ +curl --location 'https://${CUSTOM_DOMAIN}/admin/v1/import' \ --header 'Content-Type: application/json' \ --header 'Accept: application/json' \ --header 'Authorization: Bearer ' \ diff --git a/docs/docs/guides/migrate/sources/keycloak.md b/docs/docs/guides/migrate/sources/keycloak.md index 8b574fe55..ac890c609 100644 --- a/docs/docs/guides/migrate/sources/keycloak.md +++ b/docs/docs/guides/migrate/sources/keycloak.md @@ -128,7 +128,7 @@ Use your **access token** or **PAT** to authenticate, then call the [Management ```bash curl --request POST \ - --url https:///admin/v1/import \ + --url https://${CUSTOM_DOMAIN}/admin/v1/import \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer ' \ --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:///admin/v1/events/_search' \ +curl --location 'https://${CUSTOM_DOMAIN}/admin/v1/events/_search' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ diff --git a/docs/docs/guides/solution-scenarios/b2c.mdx b/docs/docs/guides/solution-scenarios/b2c.mdx index ed5e98632..25e2be938 100644 --- a/docs/docs/guides/solution-scenarios/b2c.mdx +++ b/docs/docs/guides/solution-scenarios/b2c.mdx @@ -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). diff --git a/docs/docs/guides/solution-scenarios/domain-discovery.mdx b/docs/docs/guides/solution-scenarios/domain-discovery.mdx index 701029f2a..07820db99 100644 --- a/docs/docs/guides/solution-scenarios/domain-discovery.mdx +++ b/docs/docs/guides/solution-scenarios/domain-discovery.mdx @@ -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 diff --git a/docs/docs/guides/solution-scenarios/restrict-console.mdx b/docs/docs/guides/solution-scenarios/restrict-console.mdx index 40372d5d2..7c352f216 100644 --- a/docs/docs/guides/solution-scenarios/restrict-console.mdx +++ b/docs/docs/guides/solution-scenarios/restrict-console.mdx @@ -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: diff --git a/docs/docs/self-hosting/deploy/troubleshooting/_instance_not_found.mdx b/docs/docs/self-hosting/deploy/troubleshooting/_instance_not_found.mdx index 76b8e7b2f..07278e455 100644 --- a/docs/docs/self-hosting/deploy/troubleshooting/_instance_not_found.mdx +++ b/docs/docs/self-hosting/deploy/troubleshooting/_instance_not_found.mdx @@ -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. diff --git a/docs/docs/self-hosting/manage/cache.md b/docs/docs/self-hosting/manage/cache.md index 484aad048..3fb2bfac7 100644 --- a/docs/docs/self-hosting/manage/cache.md +++ b/docs/docs/self-hosting/manage/cache.md @@ -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] diff --git a/docs/docs/self-hosting/manage/custom-domain.md b/docs/docs/self-hosting/manage/custom-domain.md index 233c505a9..02fd7d78c 100644 --- a/docs/docs/self-hosting/manage/custom-domain.md +++ b/docs/docs/self-hosting/manage/custom-domain.md @@ -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' diff --git a/docs/docs/support/troubleshooting.mdx b/docs/docs/support/troubleshooting.mdx index 29a8aba83..eaf520ac5 100644 --- a/docs/docs/support/troubleshooting.mdx +++ b/docs/docs/support/troubleshooting.mdx @@ -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/). diff --git a/docs/sidebars.js b/docs/sidebars.js index fbec819d9..111678705 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -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." diff --git a/docs/src/components/environment.jsx b/docs/src/components/environment.jsx index 9bf3825e7..5abc5def2 100644 --- a/docs/src/components/environment.jsx +++ b/docs/src/components/environment.jsx @@ -39,7 +39,7 @@ export function SetEnvironment() { return (
- +