mirror of
https://github.com/andwati/zitadel.git
synced 2026-11-11 16:45:13 +00:00
docs: fixed some typos, formatting, grammar (#11540)
# Which Problems Are Solved - Typos - Punctuation - Markdown table formatting - ... (A bunch of issues my editor gave) # How the Problems Are Solved # Additional Changes # Additional Context
This commit is contained in:
Wim Van Laer
@@ -18,10 +18,10 @@ ZITADEL provides different solutions how to send events to external systems, the
|
||||
The following table shows the available integration patterns for streaming audit logs to external systems.
|
||||
|
||||
| | Description | Self-hosting | ZITADEL Cloud |
|
||||
|-------------------------------------|----------------------------------------------------------------------------------------------------------------|-------------|---------------|
|
||||
| Events-API | Pulling events of all ZITADEL resources such as Users, Projects, Apps, etc. (Events = Change Log of Resources) | ✅ | ✅ |
|
||||
| ZITADEL Actions Log to Stdout | Custom log to messages possible on predefined triggers during login / register Flow | ✅ | ❌ |
|
||||
| ZITADEL Actions trigger API/Webhook | Custom API/Webhook request on predefined triggers during login / register | ✅ | ✅ |
|
||||
|-------------------------------------|----------------------------------------------------------------------------------------------------------------|--------------|---------------|
|
||||
| Events-API | Pulling events of all ZITADEL resources such as Users, Projects, Apps, etc. (Events = Change Log of Resources) | ✅ | ✅ |
|
||||
| ZITADEL Actions Log to Stdout | Custom log to messages possible on predefined triggers during login / register Flow | ✅ | ❌ |
|
||||
| ZITADEL Actions trigger API/Webhook | Custom API/Webhook request on predefined triggers during login / register | ✅ | ✅ |
|
||||
|
||||
### Events API
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ You will have to paste it in the Apple service later.
|
||||
Go back [to the Apple provider template you opened before in ZITADEL](#open-the-apple-identity-provider-template).
|
||||
|
||||
1. Add the Client ID, this is [the identifier of the service you created in your Apple Account](#register-a-new-service)
|
||||
2. Fill the Team ID, you can find it when you login to your Apple Developer account, in your membership
|
||||
2. Fill the Team ID, you can find it when you log in to your Apple Developer account, in your membership
|
||||
3. Enter the [Key ID and upload the Private Key you created before](#register-a-new-key)
|
||||
|
||||
You can optionally configure the following settings.
|
||||
|
||||
@@ -28,7 +28,7 @@ You need to have access to an Entra ID Tenant. If you do not yet have one follow
|
||||
### Register a new application
|
||||
|
||||
1. Browse to the [App registration menus create dialog](https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/CreateApplicationBlade/quickStartType~/null/isMSAApp~/false) to create a new app.
|
||||
2. Give the application a name and choose who should be able to login (Single-Tenant, Multi-Tenant, Personal Accounts, etc.) This setting will also have an impact on how to configure the provider later on in ZITADEL.
|
||||
2. Give the application a name and choose who should be able to log in (Single-Tenant, Multi-Tenant, Personal Accounts, etc.) This setting will also have an impact on how to configure the provider later on in ZITADEL.
|
||||
3. Choose "Web" in the redirect uri field and [paste the ZITADEL Callback URL you copied before](#open-the-microsoft-identity-provider-template).
|
||||
4. Save the Application (client) ID and the Directory (tenant) ID from the detail page
|
||||
5. Register the application
|
||||
@@ -42,7 +42,7 @@ You need to have access to an Entra ID Tenant. If you do not yet have one follow
|
||||
Generate a new client secret to authenticate your user.
|
||||
|
||||
1. Click on client credentials on the detail page of the application or use the menu "Certificates & secrets"
|
||||
2. Click on "+ New client secret" and enter a description and an expiry date, add the secret afterwards
|
||||
2. Click on "+ New client secret" and enter a description and an expiry date, add the secret afterward
|
||||
3. Copy the value of the secret. You will not be able to see the value again after some time
|
||||
|
||||
|
||||
@@ -84,7 +84,7 @@ If you want to avoid that, make sure to enable "Email verified".
|
||||
In that case, the user is created with a verified email address.
|
||||
|
||||
**Tenant Type**: Configure the tenant type according to what you have chosen in the settings of your Entra ID application previously.
|
||||
- Common: Choose common if you want all Microsoft accounts being able to login.
|
||||
- Common: Choose common if you want all Microsoft accounts being able to log in.
|
||||
In this case, configure "Accounts in any organizational directory and personal Microsoft accounts" in your Entra ID App.
|
||||
- Organizations: Choose organization if you have Entra ID Tenants and no personal accounts. (You have configured either "Accounts in this organization" or "Accounts in any organizational directory" on your Azure APP)
|
||||
- Consumers: Choose this if you want to allow public accounts. (In your Entra ID App you have configured "Personal Microsoft accounts only")
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
Your user has successfully authenticated, and now you ask them if they want to setup MFA to have a more secure account.
|
||||
Your user has successfully authenticated, and now you ask them if they want to set up MFA to have a more secure account.
|
||||
When the user starts the configuration, first you want to show them the possible methods.
|
||||
You can either list it implicitly or call the settings service from ZITADEL to get what is configured on the login settings.
|
||||
|
||||
@@ -14,7 +14,7 @@ curl --request GET \
|
||||
```
|
||||
|
||||
Response Example:
|
||||
The relevant part for the list is the second factor and multi-factor list.
|
||||
The relevant part for the list is the second factor and multifactor list.
|
||||
|
||||
```bash
|
||||
{
|
||||
|
||||
@@ -13,14 +13,14 @@ This documentation aims to guide you through the process of seamlessly integrati
|
||||
|
||||
## Why Integrate with Zitadel?
|
||||
|
||||
ZITADEL offers a comprehensive identity and access management solution, providing features like single sign-on (SSO), multi-factor authentication (MFA), user management, and more. By integrating your application with ZITADEL, you can leverage these powerful features to enhance the security and usability of your application without reinventing the wheel.
|
||||
ZITADEL offers a comprehensive identity and access management solution, providing features like single sign-on (SSO), multifactor authentication (MFA), user management, and more. By integrating your application with ZITADEL, you can leverage these powerful features to enhance the security and usability of your application without reinventing the wheel.
|
||||
|
||||
## Getting Started
|
||||
|
||||
To begin integrating your application with Zitadel using RFC 8628, follow the steps outlined in this documentation. We'll walk you through the process, from setting up your application in the Zitadel management console to handling user authentication and access tokens in your application code.
|
||||
|
||||
1. Go to “Organization”/”Projects”.
|
||||
2. Under “Applications” click the “New” button.
|
||||
1. Go to "Organization"/"Projects".
|
||||
2. Under "Applications" click the "New" button.
|
||||
|
||||
<img src="/docs/img/device-auth/device-auth-01.png" alt="Device Authorization Flow in ZITADEL"/>
|
||||
|
||||
|
||||
@@ -10,12 +10,12 @@ This guide shows you the different concepts and use cases of the logout process
|
||||
### Single Sign On (SSO) vs Single Logout (SLO)
|
||||
|
||||
Single Sign On (SSO) allows a user to login once without the need for authentication across multiple applications.
|
||||
Single Logout (SLO) is the counterpart to SSO. With SLO a user can logout and terminate sessions across many applications, without actively logging out from them.
|
||||
Single Logout (SLO) is the counterpart to SSO. With SLO a user can log out and terminate sessions across many applications, without actively logging out from them.
|
||||
|
||||
The purpose of a logout is to terminate a user session.
|
||||
Depending on how the session handling is implemented, there are different mechanisms that can be used.
|
||||
There are two possibilities where sessions are stored:
|
||||
- The User Agent (e.g the Browser or Mobile App) stores the session information (e.g. in a cookie)
|
||||
- The User Agent (e.g. the Browser or Mobile App) stores the session information (e.g. in a cookie)
|
||||
- A Server stores the session information (e.g. in a database or api)
|
||||
|
||||
### OpenID Connect Logout
|
||||
@@ -27,14 +27,14 @@ OpenID Connect defines three logout mechanisms to address the different architec
|
||||
|
||||
#### Session Management
|
||||
|
||||
Session Management in OpenID Connect defines a mechanism for a client (Relying Party, RP) to monitor the state of the user session from a identity provider (OP, e.g ZITADEL).
|
||||
Session Management in OpenID Connect defines a mechanism for a client (Relying Party, RP) to monitor the state of the user session from an identity provider (OP, e.g. ZITADEL).
|
||||
When a user logs out of the provider, the user's session is terminated and the client can in turn reflect that in its behavior.
|
||||
|
||||
#### RP initiated Logout
|
||||
|
||||
With the RP initiated flow all logout processes are triggered by a request from the client (e.g your application) through a well defined standard API by redirecting the user-agent to the [end_session_endpoint](/apis/openidoauth/endpoints#end-session-endpoint).
|
||||
With the RP initiated flow all logout processes are triggered by a request from the client (e.g. your application) through a well-defined standard API by redirecting the user-agent to the [end_session_endpoint](/apis/openidoauth/endpoints#end-session-endpoint).
|
||||
If you have specified some post_logout_redirect_uris on your client you have to send either the id_token_hint or the client_id as param in your request.
|
||||
So ZITADEL is able to read the configured redirect uris.
|
||||
So ZITADEL is able to read the configured redirect URIs.
|
||||
|
||||
```
|
||||
GET ${CUSTOM_DOMAIN}/oidc/v1/end_session
|
||||
@@ -55,7 +55,7 @@ This is not yet implemented in ZITADEL
|
||||
#### Back-Channel Logout
|
||||
|
||||
The back-channel logout is a mechanism on the server-side and the user agent does not have to do anything.
|
||||
The user will logout from all clients even in the case the user agent was closed.
|
||||
The user will log out from all clients even in the case the user agent was closed.
|
||||
|
||||
<Callout>
|
||||
This is not yet implemented in ZITADEL
|
||||
|
||||
@@ -7,11 +7,11 @@ sidebar_label: Recommended authorization flows
|
||||
|
||||
In this guide we will go over some basics on how to obtain an authorization with OpenID Connect 1.x and OAuth 2.x.
|
||||
|
||||
ZITADEL does not make assumptions about the application type you are about to integrate. Therefore you must qualify and define an appropriate method for your users to gain authorization to access your application (“authentication flow”). Your choice depends on the application’s ability to maintain the confidentiality of client credentials and the technological capabilities of your application. If you choose a deprecated or unfeasible flow to obtain authorization for your application, your users’ credentials may be compromised.
|
||||
ZITADEL does not make assumptions about the application type you are about to integrate. Therefore, you must qualify and define an appropriate method for your users to gain authorization to access your application (“authentication flow”). Your choice depends on the application’s ability to maintain the confidentiality of client credentials and the technological capabilities of your application. If you choose a deprecated or unfeasible flow to obtain authorization for your application, your users’ credentials may be compromised.
|
||||
|
||||
We invite you to further explore the different authorization flows in the OAuth 2.x standard. For the start we assume that you have a brand-new application (ie. without legacy requirements) and you found an reliable SDK/Library that does the heavy lifting for you.
|
||||
We invite you to further explore the different authorization flows in the OAuth 2.x standard. For the start we assume that you have a brand-new application (i.e. without legacy requirements) and you found a reliable SDK/Library that does the heavy lifting for you.
|
||||
|
||||
So this module will only go over the basics and explain why we recommend the flow “Authorization Flow with PKCE” as default for most applications. We will also cover the case of machine-to-machine communication, ie. where there is no interactive login. Further we will guide you to further reading viable alternatives, if the default flow is not feasible.
|
||||
So this module will only go over the basics and explain why we recommend the flow “Authorization Flow with PKCE” as default for most applications. We will also cover the case of machine-to-machine communication, i.e. where there is no interactive login. Further we will guide you to further reading viable alternatives, if the default flow is not feasible.
|
||||
|
||||
## Basics of Federated Identity
|
||||
|
||||
@@ -28,12 +28,12 @@ So what do we want to achieve with delegated authentication?
|
||||
|
||||
- Instead of implementing authentication on each server and trusting each server
|
||||
|
||||
- Users only **authenticate** with a trusted server (ie. ZITADEL), that validates the user’s identity through a challenge (eg, multiple authentication factors) and issues an **ID token** (OpenID Connect 1.x)
|
||||
- Users only **authenticate** with a trusted server (i.e. ZITADEL), that validates the user’s identity through a challenge (eg, multiple authentication factors) and issues an **ID token** (OpenID Connect 1.x)
|
||||
- Applications have means of **validating the integrity** of presented access and ID tokens
|
||||
|
||||
- Instead of sending around the user’s credentials
|
||||
- Clients may access protected resources with an **access token** that is only valid for specific scope and limited lifetime (OAuth 2.x)
|
||||
- Users have to **authorize** applications to access certain [**scopes**](/apis/openidoauth/scopes) (eg, email address or custom roles). Applications can request [**claims**](/apis/openidoauth/claims) (key:value pairs, eg email address) for the authorized scopes with the access token or ID token from ZITADEL
|
||||
- Users have to **authorize** applications to access certain [**scopes**](/apis/openidoauth/scopes) (eg, email address or custom roles). Applications can request [**claims**](/apis/openidoauth/claims) (key:value pairs, e.g. email address) for the authorized scopes with the access token or ID token from ZITADEL
|
||||
- Access tokens are bearer tokens, meaning that possession of the token provides access to a resource. But the tokens expire frequently and the application must request a new access token via **refresh token** or the user must reauthenticate
|
||||
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ ZITADEL implements the [RFC7517 - JSON Web Key (JWK)](https://www.rfc-editor.org
|
||||
Web keys in ZITADEL support a number of [JSON Web Algorithms (JWA)](https://www.rfc-editor.org/rfc/rfc7518) for digital signatures:
|
||||
|
||||
| Identifier | Description |
|
||||
| ---------- | ------------------------------- |
|
||||
|------------|---------------------------------|
|
||||
| RS256 | RSASSA-PKCS1-v1_5 using SHA-256 |
|
||||
| RS384 | RSASSA-PKCS1-v1_5 using SHA-384 |
|
||||
| RS512 | RSASSA-PKCS1-v1_5 using SHA-512 |
|
||||
@@ -73,7 +73,7 @@ Since the decision in the proposal isn't published yet,
|
||||
there is a big change some OIDC client libraries don't have proper support for EdDSA / ed25519.
|
||||
|
||||
The ZITADEL back-end is written in Go. The Go developers have denied ed448 curve implementations to be included.
|
||||
Therefore ZITADEL only uses ed25519 with a SHA512.
|
||||
Therefore, ZITADEL only uses ed25519 with a SHA512.
|
||||
The same counts for [zitadel/oidc](https://github.com/zitadel/oidc) Go library.
|
||||
|
||||
## Web Key management
|
||||
@@ -127,7 +127,7 @@ The RSA generator config takes two enum values.
|
||||
- `RSA_HASHER_SHA384` results in the RS384 algorithm header.
|
||||
- `RSA_HASHER_SHA512` results in the RS512 algorithm header.
|
||||
|
||||
For example, to create a RSA web key with the size of 3072 bits and the SHA512 algorithm (RS512):
|
||||
For example, to create an RSA web key with the size of 3072 bits and the SHA512 algorithm (RS512):
|
||||
|
||||
```bash
|
||||
curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
|
||||
@@ -175,7 +175,7 @@ Note that the `alg` header for ed25519 is `EdDSA` and refers to both ed25519 and
|
||||
Both curves specify different hashers.
|
||||
Clients which support both curves must inspect `crv` header value to assert the difference.
|
||||
|
||||
For example, to create a ed25519 web key:
|
||||
For example, to create an ed25519 web key:
|
||||
|
||||
```bash
|
||||
curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
|
||||
@@ -188,7 +188,7 @@ curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
|
||||
```
|
||||
|
||||
[^2]: The ZITADEL back-end is written in Go. The Go developers have denied ed448 curve implementations to be included.
|
||||
Therefore ZITADEL won't support this either.
|
||||
Therefore, ZITADEL won't support this either.
|
||||
|
||||
### Activation
|
||||
|
||||
@@ -198,7 +198,7 @@ There can be only one active key on an instance.
|
||||
Activating a key implies deactivation of the previously active key.
|
||||
|
||||
Public keys on the [JWKS](#json-web-key-set) endpoint may be [cached](#caching).
|
||||
Therefore it is advised to delay activation after generating a key,
|
||||
Therefore, it is advised to delay activation after generating a key,
|
||||
at least for the duration of the max-age setting plus any time it might take for client applications to refresh.
|
||||
|
||||
### Deletion
|
||||
@@ -207,8 +207,8 @@ Non-active keys may be [deleted](/apis/resources/webkey_service_v2/zitadel-webke
|
||||
Deletion also means tokens signed with this key become invalid.
|
||||
Active keys can't be deleted.
|
||||
As each public key is available on the [JWKS](#json-web-key-set) endpoint,
|
||||
it is important to cleanup old web keys that are no longer needed.
|
||||
Otherwise the endpoint's response size will only grow over time, which might lead to performance issues.
|
||||
it is important to clean up old web keys that are no longer needed.
|
||||
Otherwise, the endpoint's response size will only grow over time, which might lead to performance issues.
|
||||
|
||||
Once a key was activated and deactivated (by activation of the next key) deletion should wait:
|
||||
|
||||
@@ -224,16 +224,16 @@ This strategy aims to fulfill the following requirements:
|
||||
1. Web keys are rotated monthly.
|
||||
2. Applications have enough time to see the next activated web key on the [JWKS](#json-web-key-set) endpoint.
|
||||
3. Web keys are kept long enough to cover the access and ID token validity of 24 hours.
|
||||
4. Web keys are kept long enough to to allow usage of the `id_token_hint` for at least 3 months.
|
||||
4. Web keys are kept long enough to allow usage of the `id_token_hint` for at least 3 months.
|
||||
Users that haven't logged in / refreshed tokens with the client application for that period,
|
||||
will need to re-enter their username.
|
||||
|
||||
When the instance was created, resp. the feature was rolled out, the instance got two keys with the first one activated. When this feature becomes generally available, instance creation will setup the first two keys in the same way. So the initial state always looks like this:
|
||||
When the instance was created, resp. the feature was rolled out, the instance got two keys with the first one activated. When this feature becomes generally available, instance creation will set up the first two keys in the same way. So the initial state always looks like this:
|
||||
|
||||
| id | created | changed | state |
|
||||
| --- | ---------- | ---------- | --------------- |
|
||||
| 1 | 2025-01-01 | 2025-01-01 | `STATE_ACTIVE` |
|
||||
| 2 | 2025-01-01 | 2025-01-01 | `STATE_INITIAL` |
|
||||
| id | created | changed | state |
|
||||
|----|------------|------------|-----------------|
|
||||
| 1 | 2025-01-01 | 2025-01-01 | `STATE_ACTIVE` |
|
||||
| 2 | 2025-01-01 | 2025-01-01 | `STATE_INITIAL` |
|
||||
|
||||
For the sake of this example we will use simplified IDs and restrict timestamps to dates.
|
||||
|
||||
@@ -253,24 +253,24 @@ curl -L 'https://${CUSTOM_DOMAIN}/v2/web_keys' \
|
||||
|
||||
Key ID 2 became active, Key ID 1 became inactive and a new key with ID 3 was created:
|
||||
|
||||
| id | created | changed | state |
|
||||
| --- | ---------- | ---------- | ---------------- |
|
||||
| 1 | 2025-01-01 | 2025-02-01 | `STATE_INACTIVE` |
|
||||
| 2 | 2025-01-01 | 2025-02-01 | `STATE_ACTIVE` |
|
||||
| 3 | 2025-02-01 | 2025-02-01 | `STATE_INITIAL` |
|
||||
| id | created | changed | state |
|
||||
|----|------------|------------|------------------|
|
||||
| 1 | 2025-01-01 | 2025-02-01 | `STATE_INACTIVE` |
|
||||
| 2 | 2025-01-01 | 2025-02-01 | `STATE_ACTIVE` |
|
||||
| 3 | 2025-02-01 | 2025-02-01 | `STATE_INITIAL` |
|
||||
|
||||
No keys are deleted yet.
|
||||
We continue like this monthly.
|
||||
At one point (on 2025-05-01) we will have a web key with `STATE_INACTIVE` with a changed date of 3 months ago:
|
||||
|
||||
| id | created | changed | state |
|
||||
| --- | ---------- | ---------- | ---------------- |
|
||||
| 1 | 2025-01-01 | 2025-02-01 | `STATE_INACTIVE` |
|
||||
| 2 | 2025-01-01 | 2025-03-01 | `STATE_INACTIVE` |
|
||||
| 3 | 2025-02-01 | 2025-04-01 | `STATE_INACTIVE` |
|
||||
| 4 | 2025-03-01 | 2025-05-01 | `STATE_INACTIVE` |
|
||||
| 5 | 2025-04-01 | 2025-05-01 | `STATE_ACTIVE` |
|
||||
| 6 | 2025-05-01 | 2025-05-01 | `STATE_INITIAL` |
|
||||
| id | created | changed | state |
|
||||
|----|------------|------------|------------------|
|
||||
| 1 | 2025-01-01 | 2025-02-01 | `STATE_INACTIVE` |
|
||||
| 2 | 2025-01-01 | 2025-03-01 | `STATE_INACTIVE` |
|
||||
| 3 | 2025-02-01 | 2025-04-01 | `STATE_INACTIVE` |
|
||||
| 4 | 2025-03-01 | 2025-05-01 | `STATE_INACTIVE` |
|
||||
| 5 | 2025-04-01 | 2025-05-01 | `STATE_ACTIVE` |
|
||||
| 6 | 2025-05-01 | 2025-05-01 | `STATE_INITIAL` |
|
||||
|
||||
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:
|
||||
@@ -283,15 +283,15 @@ curl -L -X DELETE 'https://${CUSTOM_DOMAIN}/v2/web_keys/1' \
|
||||
|
||||
The final state:
|
||||
|
||||
| id | created | changed | state |
|
||||
| --- | ---------- | ---------- | ---------------- |
|
||||
| 2 | 2025-01-01 | 2025-03-01 | `STATE_INACTIVE` |
|
||||
| 3 | 2025-02-01 | 2025-04-01 | `STATE_INACTIVE` |
|
||||
| 4 | 2025-03-01 | 2025-05-01 | `STATE_INACTIVE` |
|
||||
| 5 | 2025-04-01 | 2025-05-01 | `STATE_ACTIVE` |
|
||||
| 6 | 2025-05-01 | 2025-05-01 | `STATE_INITIAL` |
|
||||
| id | created | changed | state |
|
||||
|----|------------|------------|------------------|
|
||||
| 2 | 2025-01-01 | 2025-03-01 | `STATE_INACTIVE` |
|
||||
| 3 | 2025-02-01 | 2025-04-01 | `STATE_INACTIVE` |
|
||||
| 4 | 2025-03-01 | 2025-05-01 | `STATE_INACTIVE` |
|
||||
| 5 | 2025-04-01 | 2025-05-01 | `STATE_ACTIVE` |
|
||||
| 6 | 2025-05-01 | 2025-05-01 | `STATE_INITIAL` |
|
||||
|
||||
Next month, Key ID 6 will be activated, an new key added and Key ID 2 can be deleted.
|
||||
Next month, Key ID 6 will be activated, a new key added and Key ID 2 can be deleted.
|
||||
|
||||
## JSON web key set
|
||||
|
||||
@@ -340,7 +340,7 @@ The legacy keys will disappear once they expire.
|
||||
As web keys can be created and distributed ahead of time, it is safe for JWKS responses to be cached at intermediate proxies.
|
||||
Once the `web_key` feature is enabled, ZITADEL will send a `Cache-Control` header which allows caching.
|
||||
|
||||
By default and in ZITADEL Cloud we allow 5 minutes of caching:
|
||||
By default, and in ZITADEL, Cloud we allow 5 minutes of caching:
|
||||
|
||||
```
|
||||
Cache-Control: max-age=300, must-revalidate
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
Per default the login ui of the default organization is shown.
|
||||
To allow users of a specific organization to register with their IDP (e.g Entra ID) you have two options.
|
||||
To allow users of a specific organization to register with their IDP (e.g. Entra ID) you have two options.
|
||||
|
||||
1. Identify organization with organization scope
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ It is an alternative to the [private key JWT](./private-key-jwt) and [client cre
|
||||
|
||||
1. Navigate to Service Users
|
||||
2. Click on **New**
|
||||
3. Enter a user name and a display name
|
||||
3. Enter a username and a display name
|
||||
4. Click on the Personal Access Token menu point in the detail of your user
|
||||
5. Click on **New**
|
||||
6. You can either set an expiration date or leave it empty if you don't want it to expire
|
||||
|
||||
@@ -89,7 +89,7 @@ Add members to your policy.
|
||||
|
||||
Now you should be all set to verify your setup:
|
||||
|
||||
- Create an user in ZITADEL with the same email address as a member in your authentication policy.
|
||||
- Create a user in ZITADEL with the same email address as a member in your authentication policy.
|
||||
- In a new browser session go to https://id.atlassian.com
|
||||
- Enter the user's email address
|
||||
- You should be redirected to ZITADEL's Login screen
|
||||
|
||||
@@ -19,7 +19,7 @@ Prerequisites:
|
||||
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
|
||||
- existing Auth0 tenant as described [here](https://auth0.com/docs/get-started/auth0-overview/create-tenants)
|
||||
|
||||
> We have to switch between ZITADEL and a Auth0. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and if the headings start with "Auth0" please switch to the Auth0 GUI.
|
||||
> We have to switch between ZITADEL and Auth0. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and if the headings start with "Auth0" please switch to the Auth0 GUI.
|
||||
|
||||
## **Auth0**: Create a new connection
|
||||
|
||||
@@ -45,8 +45,8 @@ First of all we create the application in your project.
|
||||
|
||||
## **Auth0**: Connect ZITADEL
|
||||
|
||||
1. Copy the client id from ZITADEL and past it into the **Client ID** field
|
||||
2. Copy the client secret from ZITADEL and past it into the **Client Secret** field
|
||||
1. Copy the client id from ZITADEL and paste it into the **Client ID** field
|
||||
2. Copy the client secret from ZITADEL and paste it into the **Client Secret** field
|
||||
|
||||
3. click Create
|
||||
4. To verify the connection go to the "Applications" tab and enable the Default App
|
||||
@@ -54,6 +54,6 @@ First of all we create the application in your project.
|
||||
5. Click "Back to OpenID Connect"
|
||||
6. Click on the "..." button right to the newly created connection and click "Try"
|
||||
|
||||
7. ZITADEL should open on a new tab and you can enter your login information
|
||||
7. ZITADEL should open on a new tab, and you can enter your login information
|
||||
8. After you logged in you should see the following:
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ Prerequisites:
|
||||
- existing ZITADEL project, if not present follow the first 3 steps [here](/guides/manage/console/projects-overview)
|
||||
- existing Auth0 tenant as described [here](https://auth0.com/docs/get-started/auth0-overview/create-tenants)
|
||||
|
||||
> We have to switch between ZITADEL and a Auth0. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and
|
||||
> We have to switch between ZITADEL and Auth0. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and
|
||||
> if the headings start with "Auth0" please switch to the Auth0 GUI.
|
||||
|
||||
## **Auth0**: Create a new connection
|
||||
@@ -70,7 +70,7 @@ Everything on the side of ZITADEL is done if the application is correctly create
|
||||
|
||||
## **Auth0**: Try the connection
|
||||
|
||||
To then test the connection you only have to press "Try" on the created connection in the Authentication -> Enterprise
|
||||
To then test the connection you only have to press "Try" on the created connection in the Authentication → Enterprise
|
||||
screen.
|
||||
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ Prerequisites:
|
||||
- prerequisites on AWS side [here](https://docs.aws.amazon.com/singlesignon/latest/userguide/prereqs.html).
|
||||
- enabled AWS SSO [here](https://docs.aws.amazon.com/singlesignon/latest/userguide/step1.html?icmpid=docs_sso_console)
|
||||
|
||||
> We have to switch between ZITADEL and a AWS. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and if
|
||||
> We have to switch between ZITADEL and AWS. If the headings begin with "ZITADEL" switch to the ZITADEL Management Console and if
|
||||
> the headings start with "AWS" please switch to the AWS GUI.
|
||||
|
||||
## **AWS**: Change to external identity provider ZITADEL
|
||||
@@ -33,7 +33,7 @@ can connect to ZITADEL as a SAML2 IDP.
|
||||
|
||||
|
||||
2. Download the metadata file, to provide ZITADEL with all the information it needs, and save the AWS SSO Sign-in URL,
|
||||
which you use to login afterwards.
|
||||
which you use to log in afterward.
|
||||
|
||||
3. Fill out the fields as follows, to provide AWS with all the information it needs:
|
||||
|
||||
@@ -75,5 +75,5 @@ Everything on the side of ZITADEL is done if the application is correctly create
|
||||
|
||||
## **AWS**: Test the connection
|
||||
|
||||
The result, you can now login to you AWS account through your ZITADEL-login with the AWS SSO Sign-in URL, which you
|
||||
The result, you can now log in to you AWS account through your ZITADEL-login with the AWS SSO Sign-in URL, which you
|
||||
should have saved in "Change to external identity provider ZITADEL" step 2.
|
||||
|
||||
@@ -26,11 +26,11 @@ Follow [this guide](https://docs.gitlab.com/ee/administration/auth/oidc.html) of
|
||||
|
||||
Replace the values of the following fields:
|
||||
|
||||
- `args.client_options.identifier` with the `ClientId` generated by ZITADEL in the last step of [Create application in ZITADEL])()
|
||||
- `args.client_options.secret` with the `ClientSecret` generated by ZITADEL in the last step of [Create application in ZITADEL])()
|
||||
- `args.client_options.identifier` with the `ClientId` generated by ZITADEL
|
||||
- `args.client_options.secret` with the `ClientSecret` generated by ZITADEL
|
||||
- `args.client_options.redirect_uri` with the proper URL to your gitlab instance and callback
|
||||
|
||||
```yaml
|
||||
```ruby
|
||||
gitlab_rails['omniauth_providers'] = [
|
||||
{
|
||||
name: "openid_connect",
|
||||
|
||||
@@ -23,8 +23,7 @@ Prerequisites:
|
||||
|
||||
## **Ping**: Create a new external identity provider
|
||||
|
||||
To add an
|
||||
additional [external identity provider](https://docs.pingidentity.com/bundle/pingone/page/jvz1567784210191.html), you
|
||||
To add an [external identity provider](https://docs.pingidentity.com/bundle/pingone/page/jvz1567784210191.html), you
|
||||
can follow the instructions [here](https://docs.pingidentity.com/bundle/pingone/page/ovy1567784211297.html)
|
||||
|
||||
1. As described you have to create a new provider, with a unique identifier:
|
||||
|
||||
@@ -6,7 +6,7 @@ This integration guide shows you the basic OpenID Connect integration with ZITAD
|
||||
|
||||
## Setup PKCE client in ZITADEL
|
||||
|
||||
- Go to your organization and setup a new application with the type PKCE
|
||||
- Go to your organization and set up a new application with the type PKCE
|
||||
- When created go to the "Redirect Settings" and *enable Development Mode*
|
||||
- Add the Redirect Uri, f.e. `http://localhost:8080/secure/callback`
|
||||
- Add the Post Logout Uri, f.e. `http://localhost:8080/index.html`
|
||||
@@ -38,14 +38,14 @@ OIDCPKCEMethod S256
|
||||
|
||||
With the following parameters
|
||||
|
||||
| Parameter | Description | Example value|
|
||||
|---|---|---|
|
||||
| OIDCProviderMetadataURL | Is the url to the discovery endpoint | `https://${CUSTOM_DOMAIN}/.well-known/openid-configuration` |
|
||||
| OIDCClientID | Is the ID of the zitadel application. You can find it on the settings page of the application. | 123456789123@apache_test |
|
||||
| OIDCRedirectURI | Users will be redirected to this page after successful login. If you are using localhost or any other non-https endpoint, make sure to enable development mode in ZITADEL. | https://mysecureapp.io/secure/callback |
|
||||
| OIDCCryptoPassphrase | Create a secure passphrase. Consult the module's documentation for more details. | ... |
|
||||
| OIDCScope | OpenID Connect scopes that should be included. You can find a list of [all scopes](/apis/openidoauth/scopes) in our documentation. | "openid profile" |
|
||||
| OIDCPKCEMethod | The method should be set to `S256` | S256 |
|
||||
| Parameter | Description | Example value |
|
||||
|-------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------|
|
||||
| OIDCProviderMetadataURL | Is the url to the discovery endpoint | `https://${CUSTOM_DOMAIN}/.well-known/openid-configuration` |
|
||||
| OIDCClientID | Is the ID of the zitadel application. You can find it on the settings page of the application. | 123456789123@apache_test |
|
||||
| OIDCRedirectURI | Users will be redirected to this page after successful login. If you are using localhost or any other non-https endpoint, make sure to enable development mode in ZITADEL. | https://mysecureapp.io/secure/callback |
|
||||
| OIDCCryptoPassphrase | Create a secure passphrase. Consult the module's documentation for more details. | ... |
|
||||
| OIDCScope | OpenID Connect scopes that should be included. You can find a list of [all scopes](/apis/openidoauth/scopes) in our documentation. | "openid profile" |
|
||||
| OIDCPKCEMethod | The method should be set to `S256` | S256 |
|
||||
|
||||
### Secure a route
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ In a second step fill out your user data like First-, Last- and Team-name.
|
||||
|
||||
|
||||
|
||||
If you did start with your email instead of a social login (e.g Google) you have to fill a password for your authentication.
|
||||
If you did start with your email instead of a social login (e.g. Google) you have to fill a password for your authentication.
|
||||
In that case you will get an initialization mail to verify your account.
|
||||
|
||||
|
||||
|
||||
@@ -18,9 +18,9 @@ You can specify a timeout and whether the action is allowed to fail too.
|
||||
<img src="/docs/img/guides/console/action.png" alt="Create Action" width="450px" />
|
||||
|
||||
To run those scripts, a flow with a trigger has to be created.
|
||||
This could for example be a **External Authentication** Flow, with a **Post Authentication** trigger.
|
||||
This could for example be an **External Authentication** Flow, with a **Post Authentication** trigger.
|
||||
|
||||
<img src="/docs/img/guides/console/flow.png" alt="Flow" width="400px" />
|
||||
|
||||
Now whenever a user gets authenticated externally with an IDP, a action is triggered after the authentication itself.
|
||||
Now whenever a user gets authenticated externally with an IDP, an action is triggered after the authentication itself.
|
||||
If you want to know more where actions can be useful, take a look at the feature [here](/concepts/features/actions) or directly jump to an example of a custom behavior [here](/guides/manage/customize/behavior).
|
||||
|
||||
@@ -20,7 +20,7 @@ In the right part of the management console you can find **ADMINISTRATORS** in t
|
||||
## Roles
|
||||
|
||||
| Name | Role | Description |
|
||||
| ----------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------ |
|
||||
|-------------------------------|-------------------------------|--------------------------------------------------------------------------------------------------------------|
|
||||
| Instance Owner | IAM_OWNER | Manage the Instance, manage all organizations with their content |
|
||||
| Instance Owner Viewer | IAM_OWNER_VIEWER | View the Instance and view all organizations with their content |
|
||||
| Instance Org Manager | IAM_ORG_MANAGER | Manage all organizations including their policies, projects and users |
|
||||
|
||||
@@ -266,7 +266,7 @@ If an account is locked, the administrator has to unlock it in the ZITADEL Manag
|
||||
|
||||
### Add organization domain as suffix to loginnames
|
||||
|
||||
If you enable this setting, all loginnames will be suffixed with the organization domain. If this settings is disabled, you have to ensure that usernames are unique over all organizations.
|
||||
If you enable this setting, all loginnames will be suffixed with the organization domain. If this setting is disabled, you have to ensure that usernames are unique over all organizations.
|
||||
|
||||
### Validate Org domains
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ Depending on your use case, multiple organizations can be created (B2B) or you c
|
||||
width="400px"
|
||||
/>
|
||||
|
||||
If your new to management console, you'll probably want to set some settings initially. Continue reading Default settings on the next page.
|
||||
If you're new to management console, you'll probably want to set some settings initially. Continue reading Default settings on the next page.
|
||||
|
||||
## Prevent management console access
|
||||
|
||||
|
||||
@@ -16,17 +16,17 @@ Before you start, make sure you have everything set up correctly.
|
||||
## Copy some information for the action
|
||||
|
||||
1. Select the **Projects** navigation item.
|
||||
1. Select a project that has a role configured.
|
||||
1. Copy the projects **Resource Id** on the screens top right.
|
||||
1. Scroll to the **ROLES** section and note some roles key.
|
||||
2. Select a project that has a role configured.
|
||||
3. Copy the projects **Resource ID** on the screens top right.
|
||||
4. Scroll to the **ROLES** section and note some roles key.
|
||||
|
||||
## Create the action
|
||||
|
||||
1. Select the **Actions** navigation item.
|
||||
1. In the **Actions <i className="las la-code"></i>** section, select the **+ New** button.
|
||||
1. Give the new action the name `addGrant`.
|
||||
1. Paste this snippet into the multiline textfield.
|
||||
1. Replace the snippets placeholders and select **Save**.
|
||||
2. In the **Actions <i className="las la-code"></i>** section, select the **+ New** button.
|
||||
3. Give the new action the name `addGrant`.
|
||||
4. Paste this snippet into the multiline text-field.
|
||||
5. Replace the snippets placeholders and select **Save**.
|
||||
|
||||
```js reference
|
||||
https://github.com/zitadel/actions/blob/main/examples/add_user_grant.js
|
||||
@@ -37,10 +37,10 @@ https://github.com/zitadel/actions/blob/main/examples/add_user_grant.js
|
||||
Now, make the action hook into the [external authentication flow](/apis/actions/external-authentication).
|
||||
|
||||
1. In the **Flows <i className="las la-exchange-alt"></i>** section, select the **+ New** button.
|
||||
1. Select the **Flow Type** _External Authentication_.
|
||||
1. Select the **Trigger Type** _Post Creation_.
|
||||
1. In the **Actions** dropdown, check _addGrant_.
|
||||
1. Select the **Save** button.
|
||||
2. Select the **Flow Type** _External Authentication_.
|
||||
3. Select the **Trigger Type** _Post Creation_.
|
||||
4. In the **Actions** dropdown, check _addGrant_.
|
||||
5. Select the **Save** button.
|
||||
|
||||
New users automatically are assigned a role now if they register by authenticating with an external identity provider.
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ The best way is to upload a ttf file after a successful upload you will see it i
|
||||
|
||||
### Advanced Settings
|
||||
|
||||
In the advanced behavior you can choose if the loginname suffix (domain e.g [email protected]) should be shown in the loginname screen or not and if the “ZITADEL watermark” should be hidden.
|
||||
In the advanced behavior you can choose if the loginname suffix (domain e.g. [email protected]) should be shown in the loginname screen or not and if the “ZITADEL watermark” should be hidden.
|
||||
|
||||
## Trigger the private labeling for the login
|
||||
|
||||
@@ -44,7 +44,7 @@ If you like to trigger your settings for your applications you have different po
|
||||
### 1. Primary Domain Scope
|
||||
|
||||
Send a [reserved scope](/apis/openidoauth/scopes) with your [authorization request](../../integrate/login/oidc/login-users) to trigger your organization.
|
||||
The primary domain scope will restrict the login to your organization, so only users of your own organization will be able to login.
|
||||
The primary domain scope will restrict the login to your organization, so only users of your own organization will be able to log in.
|
||||
|
||||
You can use our [OpenID Authentication Request Playground](https://zitadel.com/playgrounds/oidc) to learn more about how to trigger an [organization's policies and branding](https://zitadel.com/playgrounds/oidc#organization-policies-and-branding).
|
||||
|
||||
|
||||
@@ -6,13 +6,13 @@ You are able to customize the texts used from ZITADEL. This is possibly on the i
|
||||
|
||||
## Message Texts
|
||||
|
||||
Sometimes the users will get an email or phone message from ZITADEL (e.g Password Reset Request).
|
||||
Sometimes the users will get an email or phone message from ZITADEL (e.g. Password Reset Request).
|
||||
ZITADEL already has some good standard texts, but maybe you would like to customize it for your organization.
|
||||
|
||||
Go to the message text policy on your organization and you will find the different kinds of messages that are sent from ZITADEL.
|
||||
Go to the message text policy on your organization, and you will find the different kinds of messages that are sent from ZITADEL.
|
||||
Choose the template and the language you like to edit.
|
||||
You can now change all the texts from a message.
|
||||
As soon as you click into a input field you will see some attribute chips below the field.
|
||||
As soon as you click into an input field you will see some attribute chips below the field.
|
||||
These are the parameters you can include on this specific message.
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ These are the parameters you can include on this specific message.
|
||||
|
||||
Like the message texts you are also able to change the texts on the login interface.
|
||||
First choose the screen and the language you like to edit.
|
||||
You will see the default texts in the input field and you can overwrite them by typing into the box.
|
||||
You will see the default texts in the input field, and you can overwrite them by typing into the box.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1 +1 @@
|
||||
If you choose to run a local instance have a look at our [deploy](/self-hosting/deploy/overview) section, where we show you different possibilities on how to run ZITADEL.
|
||||
If you choose to run a local instance have a look at our [deploy-section](/self-hosting/deploy/overview), where we show you different possibilities on how to run ZITADEL.
|
||||
|
||||
Reference in New Issue
Block a user