mirror of
https://github.com/zitadel/zitadel.git
synced 2025-08-12 05:07:31 +00:00
fix: Domains problematic (#6564)
* docs: disable validate org domains per default, and have a better label * docs: rename to $CUSTOM-DOMAIN * docs: translation * docs: tranlsations * docs: tranlsations * docs: allow domain discovery --------- Co-authored-by: Max Peintner <max@caos.ch>
This commit is contained in:
@@ -46,7 +46,7 @@ JWT
|
||||
|
||||
| Claim | Example | Description |
|
||||
|:------|:---------------------------|:----------------------------------------------------------------------------------------------------------------|
|
||||
| aud | `"https://{your_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://{your_domain}",
|
||||
"aud": "https://$CUSTOM-DOMAIN",
|
||||
"exp": 1605183582,
|
||||
"iat": 1605179982
|
||||
}
|
||||
|
@@ -43,7 +43,7 @@ Please check below the matrix for an overview where which scope is asserted.
|
||||
| Claims | Example | Description |
|
||||
|:-------------------|:-----------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| acr | TBA | TBA |
|
||||
| address | `Lerchenfeldstrasse 3, 9014 St. Gallen` | TBA |
|
||||
| address | `Lerchenfeldstrasse 3, 9014 St. Gallen` | TBA |
|
||||
| amr | `pwd mfa` | Authentication Method References as defined in [RFC8176](https://tools.ietf.org/html/rfc8176) <br/> `password` value is deprecated, please check `pwd` |
|
||||
| aud | `69234237810729019` | The audience of the token, by default all client id's and the project id are included |
|
||||
| auth_time | `1311280969` | Unix time of the authentication |
|
||||
@@ -55,7 +55,7 @@ Please check below the matrix for an overview where which scope is asserted.
|
||||
| gender | `other` | Gender of the subject |
|
||||
| given_name | `Road` | Given name of the subject |
|
||||
| iat | `1311280970` | Time of the token was issued at (as unix time) |
|
||||
| iss | `{your_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 |
|
||||
|
@@ -76,19 +76,19 @@ Key JSON
|
||||
|
||||
JWT
|
||||
|
||||
| Claim | Example | Description |
|
||||
|:------|:--------------------------|:--------------------------------------------------------------------------------------------------------------|
|
||||
| aud | `"https://{your_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 |
|
||||
| sub | `"77479219772321307"` | The subject ID of the service user, normally the `userId` from the json key file |
|
||||
| Claim | Example | Description |
|
||||
|:------|:-------------------------|:--------------------------------------------------------------------------------------------------------------|
|
||||
| aud | `"https://$CUSTOM-DOMAIN"` | String or Array of intended audiences MUST include ZITADEL's issuing domain |
|
||||
| exp | `1605183582` | Unix timestamp of the expiry |
|
||||
| iat | `1605179982` | Unix timestamp of the creation singing time of the JWT, MUST NOT be older than 1h |
|
||||
| iss | `"77479219772321307"` | String which represents the requesting party (owner of the key), normally the `userId` from the json key file |
|
||||
| sub | `"77479219772321307"` | The subject ID of the service user, normally the `userId` from the json key file |
|
||||
|
||||
```JSON
|
||||
{
|
||||
"iss": "77479219772321307",
|
||||
"sub": "77479219772321307",
|
||||
"aud": "https://{your_domain}",
|
||||
"aud": "https://$CUSTOM-DOMAIN",
|
||||
"exp": 1605183582,
|
||||
"iat": 1605179982
|
||||
}
|
||||
|
@@ -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 {your_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
|
||||
|
||||
{your_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
|
||||
|
||||
{your_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.
|
||||
|
@@ -27,7 +27,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/overview).
|
||||
Go to your instance settings and then click on the Tab **Events** to open the Event Viewer or browse to $YOUR_DOMAIN/ui/console/events
|
||||
Go to your instance settings and then click on the Tab **Events** to open the Event Viewer or browse to $CUSTOM-DOMAIN/ui/console/events
|
||||
|
||||

|
||||
|
||||
|
@@ -139,7 +139,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 _{your_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
|
||||
|
@@ -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://{your_domain}.zitadel.cloud"
|
||||
oidc_issuer_url = "https://$CUSTOM-DOMAIN"
|
||||
upstreams = [
|
||||
"https://example.corp.com"
|
||||
]
|
||||
|
@@ -44,7 +44,7 @@ Use the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to include the ZITADE
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
--url {your_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 email urn:zitadel:iam:org:project:id:zitadel:aud' \
|
||||
|
@@ -59,7 +59,7 @@ The JWT payload will need to contain the following claims:
|
||||
{
|
||||
"iss": "<userid>",
|
||||
"sub": "<userid>",
|
||||
"aud": "<https://your_domain>",
|
||||
"aud": "<https://$CUSTOM-DOMAIN>",
|
||||
"exp": <now+1h>,
|
||||
"iat": <now>
|
||||
}
|
||||
@@ -95,7 +95,7 @@ Now that you configured ZITADEL and created a JWT, you can call the System API a
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
--url {your_domain}/system/v1/instances/_search \
|
||||
--url $CUSTOM-DOMAIN/system/v1/instances/_search \
|
||||
--header 'Authorization: Bearer {token}' \
|
||||
--header 'Content-Type: application/json'
|
||||
```
|
||||
|
@@ -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://{your_domain}.zitadel.cloud/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:
|
||||
|
@@ -41,7 +41,7 @@ You will need to craft a POST request to ZITADEL's token endpoint:
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
--url https://{your_domain}.zitadel.cloud/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 \
|
||||
@@ -72,7 +72,7 @@ In this example we read the organization of the service user.
|
||||
|
||||
```bash
|
||||
curl --request GET \
|
||||
--url {your-domain}/management/v1/orgs/me \
|
||||
--url $CUSTOM-DOMAIN/management/v1/orgs/me \
|
||||
--header 'Authorization: Bearer ${TOKEN}'
|
||||
```
|
||||
|
||||
|
@@ -24,7 +24,7 @@ To further restrict your result you can add the following filters:
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
--url $YOUR-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 $YOUR-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 $YOUR-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 $YOUR-DOMAIN/admin/v1/events/_search \
|
||||
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
|
||||
--header "Authorization: Bearer $TOKEN" \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
@@ -121,7 +121,7 @@ Also we include the refresh tokens in this example to know when the user has bec
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
--url $YOUR-DOMAIN/admin/v1/events/_search \
|
||||
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
|
||||
--header "Authorization: Bearer $TOKEN" \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
@@ -147,7 +147,7 @@ In this case this are the following events:
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
--url $YOUR-DOMAIN/admin/v1/events/_search \
|
||||
--url $CUSTOM-DOMAIN/admin/v1/events/_search \
|
||||
--header "Authorization: Bearer $TOKEN" \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
|
@@ -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 {your_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
|
||||
|
@@ -41,6 +41,6 @@ In this example we read the organization of the service user.
|
||||
|
||||
```bash
|
||||
curl --request GET \
|
||||
--url {your-domain}/management/v1/orgs/me \
|
||||
--url $CUSTOM-DOMAIN/management/v1/orgs/me \
|
||||
--header 'Authorization: Bearer {PAT}'
|
||||
```
|
@@ -68,7 +68,7 @@ Payload
|
||||
{
|
||||
"iss": "100507859606888466",
|
||||
"sub": "100507859606888466",
|
||||
"aud": "https://{your_domain}.zitadel.cloud",
|
||||
"aud": "https://$CUSTOM-DOMAIN",
|
||||
"iat": [Current UTC timestamp, e.g. 1605179982, max. 1 hour ago],
|
||||
"exp": [UTC timestamp, e.g. 1605183582]
|
||||
}
|
||||
@@ -90,7 +90,7 @@ With the encoded JWT from the prior step, you will need to craft a POST request
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
--url https://{your_domain}.zitadel.cloud/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 profile email' \
|
||||
@@ -122,7 +122,7 @@ For this example let's call the userinfo endpoint to verify that our access toke
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
--url https://{your_domain}.zitadel.cloud/oidc/v1/userinfo \
|
||||
--url $CUSTOM-DOMAIN/oidc/v1/userinfo \
|
||||
--header 'Content-Type: application/x-www-form-urlencoded' \
|
||||
--header 'Authorization: Bearer MtjHodGy4zxKylDOhg6kW90WeEQs2q...'
|
||||
```
|
||||
@@ -135,7 +135,7 @@ Content-Type: application/json
|
||||
|
||||
{
|
||||
"name": "MyServiceUser",
|
||||
"preferred_username": "service_user@{your_domain}.zitadel.cloud",
|
||||
"preferred_username": "service_user@$CUSTOM-DOMAIN",
|
||||
"updated_at": 1616417938
|
||||
}
|
||||
```
|
||||
|
@@ -83,7 +83,7 @@ Alternatively, you can include the claims `urn:iam:org:project:roles` or/and `ur
|
||||
|
||||
### Retrieve roles from the userinfo endpoint
|
||||
|
||||
The user info endpoint is **ZITADEL_DOMAIN/oidc/v1/userinfo**.
|
||||
The user info endpoint is **$CUSTOM-DOMAIN/oidc/v1/userinfo**.
|
||||
|
||||
This endpoint will return information about the authenticated user.
|
||||
Send the access token of the user as `Bearer Token` in the `Authorization` header:
|
||||
@@ -91,7 +91,7 @@ Send the access token of the user as `Bearer Token` in the `Authorization` heade
|
||||
**cURL Request:**
|
||||
```bash
|
||||
curl --request GET \
|
||||
--url $ZITADEL_DOMAIN/oidc/v1/userinfo
|
||||
--url $CUSTOM-DOMAIN/oidc/v1/userinfo
|
||||
--header 'Authorization: Bearer <TOKEN>'
|
||||
```
|
||||
|
||||
@@ -206,11 +206,11 @@ Let’s start with a user who has multiple roles in different organizations in a
|
||||
|
||||
Returns a list of roles for the authenticated user and for the requesting project (based on the token).
|
||||
|
||||
**URL: https://$ZITADEL_DOMAIN/auth/v1/permissions/me/_search**
|
||||
**URL: https://$CUSTOM-DOMAIN/auth/v1/permissions/me/_search**
|
||||
|
||||
**cURL request:**
|
||||
```bash
|
||||
curl -L -X POST 'https://$ZITADEL_DOMAIN/auth/v1/permissions/me/_search' \
|
||||
curl -L -X POST 'https://$CUSTOM-DOMAIN/auth/v1/permissions/me/_search' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>'
|
||||
```
|
||||
@@ -231,12 +231,12 @@ Returns a list of permissions the authenticated user has in ZITADEL based on the
|
||||
|
||||
This request can be used if you are building a management UI. For instance, if the UI is managing users, you can show the management functionality based on the permissions the user has. Here’s an example: if the user has `user.read` and `user.write` permission you can show the edit buttons, if the user only has `user.read` permission, you can hide the edit buttons.
|
||||
|
||||
**URL: https://ZITADEL_DOMAIN/auth/v1/permissions/zitadel/me/_search**
|
||||
**URL: https://$CUSTOM-DOMAIN/auth/v1/permissions/zitadel/me/_search**
|
||||
|
||||
**cURL Request:**
|
||||
|
||||
```bash
|
||||
curl -L -X POST 'https://$ZITADEL_DOMAIN/auth/v1/permissions/zitadel/me/_search' \
|
||||
curl -L -X POST 'https://$CUSTOM-DOMAIN/auth/v1/permissions/zitadel/me/_search' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>'
|
||||
```
|
||||
@@ -277,12 +277,12 @@ curl -L -X POST 'https://$ZITADEL_DOMAIN/auth/v1/permissions/zitadel/me/_search'
|
||||
|
||||
Returns a list of user grants the authenticated user has. User grants consist of an organization, a project and roles.
|
||||
|
||||
**URL: https://$ZITADEL_DOMAIN/auth/v1/usergrants/me/_search**
|
||||
**URL: https://$CUSTOM-DOMAIN/auth/v1/usergrants/me/_search**
|
||||
|
||||
**cURL request:**
|
||||
|
||||
```bash
|
||||
curl -L -X POST 'https://$ZITADEL_DOMAIN/auth/v1/usergrants/me/_search' \
|
||||
curl -L -X POST 'https://$CUSTOM-DOMAIN/auth/v1/usergrants/me/_search' \
|
||||
-H 'Content-Type: application/json' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>' \
|
||||
@@ -379,7 +379,7 @@ curl -L -X POST 'https://$ZITADEL_DOMAIN/auth/v1/usergrants/me/_search' \
|
||||
### Retrieve roles using the management API
|
||||
Now we will use the management API to retrieve user roles under an admin user.
|
||||
|
||||
The base URL is: **https://$ZITADEL_DOMAIN/management/v1**
|
||||
The base URL is: **https://$CUSTOM-DOMAIN/management/v1**
|
||||
|
||||
In [APIs listed under user grants in the management API](/docs/category/apis/resources/mgmt/user-grants), you will see that you can use the management API to retrieve and modify user grants. The two API paths that we are interested in to fetch user roles are given below.
|
||||
|
||||
@@ -389,12 +389,12 @@ In [APIs listed under user grants in the management API](/docs/category/apis/res
|
||||
|
||||
Returns a list of user roles that match the search queries. A user with manager permissions will call this API and will also have to reside in the same organization as the user.
|
||||
|
||||
**URL: https://$ZITADEL_DOMAIN/management/v1/users/grants/_search**
|
||||
**URL: https://$CUSTOM-DOMAIN/management/v1/users/grants/_search**
|
||||
|
||||
**cURL request:**
|
||||
|
||||
```bash
|
||||
curl -L -X POST 'https://$ZITADEL_DOMAIN/management/v1/users/grants/_search' \
|
||||
curl -L -X POST 'https://$CUSTOM-DOMAIN/management/v1/users/grants/_search' \
|
||||
-H 'Content-Type: application/json' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>' \
|
||||
|
@@ -51,7 +51,7 @@ Check your application, if everything is correct, press "Create".
|
||||
|
||||
Complete the configuration as follows:
|
||||
|
||||
- `Identity provider single sign-on URL`: {your_instance_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.
|
||||
|
@@ -56,7 +56,7 @@ A free instance can be upgraded to a "pay as you go" instance. By upgrading your
|
||||
### Add Custom Domain
|
||||
|
||||
We recommend register a custom domain to access your ZITADEL instance.
|
||||
The primary domain of your ZITADEL instance will be the issuer of the instance. All other domains can be used to access the instance itself
|
||||
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 your instance
|
||||
2. Click **Add custom domain**
|
||||
@@ -73,7 +73,7 @@ Be aware that it has some impacts if you change the primary domain of your insta
|
||||
|
||||

|
||||
|
||||
#### Verify Domain
|
||||
#### Verify Custom Domain
|
||||
|
||||
If you need a custom domain for your ZITADEL instance, you need to verify the domain.
|
||||
|
||||
|
@@ -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 a organization. `<https://{your-domain}-{random string}.zitadel.cloud/ui/login/register/org`
|
||||
If you want to enable your customers to create their organization by themselves, we provide a creation form for a organization. `<https://$CUSTOM-DOMAIN/ui/login/register/org`
|
||||
The customer needs to fill in the form with the organization name and the contact details.
|
||||
|
||||
<img
|
||||
|
@@ -50,7 +50,7 @@ Request the user information by calling the [userinfo endpoint](/docs/apis/openi
|
||||
|
||||
```bash
|
||||
curl --request GET \
|
||||
--url "https://$ZITADEL_DOMAIN/oidc/v1/userinfo" \
|
||||
--url "https://$CUSTOM-DOMAIN/oidc/v1/userinfo" \
|
||||
--header "Authorization: Bearer $ACCESS_TOKEN"
|
||||
```
|
||||
|
||||
@@ -166,7 +166,7 @@ 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://$ZITADEL_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" \
|
||||
@@ -188,7 +188,7 @@ curl -L -X POST "https://$ZITADEL_DOMAIN/auth/v1/users/me/metadata/_search" \
|
||||
```
|
||||
|
||||
Replace `$ACCESS_TOKEN` with your user's access token.
|
||||
Replace `$ZITADEL_DOMAIN` with your ZITADEL instance's url.
|
||||
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
|
||||
|
Reference in New Issue
Block a user