TheArchive/zitadel
1
0
Fork 0
mirror of https://github.com/zitadel/zitadel.git synced 2025-08-11 14:37:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: product roadmap and zitadel versions (#9838)

Browse Source 
# Which Problems Are Solved

The current public roadmap can be hard to understand for customers and
it doesn't show the timelines for the different versions. which results
in a lot of requests.
It only outlines what is already fixed on the timeline, but doesn't give
any possibilities to outline future topics / features, which not yet
have a timeline

# How the Problems Are Solved

A new roadmap page is added
- Outline for each version when it will have which state
- Outline different zitadel versions with its features, deprecations,
breaking changes, etc.
- Show future topics, which are not yet on the roadmap
This commit is contained in:
Fabienne Bühler
2025-06-03 15:44:04 +02:00
committed by GitHub
parent 15902f5bc7
commit b8ff83454e
19 changed files with 842 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/docs/apis/introduction.mdx
View File

@@ -45,7 +45,7 @@ The [OIDC Playground](https://zitadel.com/playgrounds/oidc) is for testing OpenI
### Custom
ZITADEL allows to authenticate users by creating a session with the [Session API](/docs/apis/resources/session_service_v2), get OIDC authentication request details with the [OIDC service API](/docs/apis/resources/oidc_service) or get SAML request details with the [SAML service API](/docs/apis/resources/saml_service).
ZITADEL allows to authenticate users by creating a session with the [Session API](/docs/apis/resources/session_service_v2), get OIDC authentication request details with the [OIDC service API](/docs/apis/resources/oidc_service_v2) or get SAML request details with the [SAML service API](/docs/apis/resources/saml_service_v2).
User authorizations can be [retrieved as roles from our APIs](/docs/guides/integrate/retrieve-user-roles).
Refer to our guide to learn how to [build your own login UI](/docs/guides/integrate/login-ui)

2
docs/docs/concepts/architecture/software.md
View File

@@ -147,5 +147,5 @@ Zitadel currently supports PostgreSQL.
Make sure to read our [Production Guide](/docs/self-hosting/manage/production#prefer-postgresql) before you decide on using one of them.
:::info
Zitadel v2 supported CockroachDB and PostgreSQL. Zitadel v3 only supports PostgreSQL. Please refer to [the mirror guide](cli/mirror) to migrate to PostgreSQL.
Zitadel v2 supported CockroachDB and PostgreSQL. Zitadel v3 only supports PostgreSQL. Please refer to [the mirror guide](/docs/self-hosting/manage/cli/mirror) to migrate to PostgreSQL.
:::

2
docs/docs/guides/integrate/actions/usage.md
View File

@@ -371,7 +371,7 @@ The API documentation to create a target can be found [here](/apis/resources/act
To ensure the integrity of request content, each call includes a 'ZITADEL-Signature' in the headers. This header contains an HMAC value computed from the request content and a timestamp, which can be used to time out requests. The logic for this process is provided in 'pkg/actions/signing.go'. The goal is to verify that the HMAC value in the header matches the HMAC value computed by the Target, ensuring that the sent and received requests are identical.
Each Target resource now contains also a Signing Key, which gets generated and returned when a Target is [created](/apis/resources/action_service_v2/action-service-create-target),
and can also be newly generated when a Target is [patched](/apis/resources/action_service_v2/action-service-patch-target).
and can also be newly generated when a Target is [patched](/apis/resources/action_service_v2/action-service-update-target).
For an example on how to check the signature, [refer to the example](/guides/integrate/actions/testing-request-signature).

4
docs/docs/guides/integrate/login-ui/device-auth.mdx
View File

@@ -102,7 +102,7 @@ Present the user with the information of the device authorization request and al
### Perform Login
After you have initialized the OIDC flow you can implement the login.
Implement all the steps you like the user the go trough by [creating](/docs/apis/resources/session_service_v2/session-service-create-session) and [updating](/docs/apis/resources/session_service/session-service-set-session) the user-session.
Implement all the steps you like the user the go trough by [creating](/docs/apis/resources/session_service_v2/session-service-create-session) and [updating](/docs/apis/resources/session_service_v2/session-service-set-session) the user-session.
Read the following resources for more information about the different checks:
- [Username and Password](./username-password)
@@ -117,7 +117,7 @@ On the create and update user session request you will always get a session toke
The latest session token has to be sent to the following request:
Read more about the [Authorize or Deny Device Authorization Request Documentation](/docs/apis/resources/oidc_service_v2/oidc-service-authorize-device-authorization)
Read more about the [Authorize or Deny Device Authorization Request Documentation](/docs/apis/resources/oidc_service_v2/oidc-service-authorize-or-deny-device-authorization)
Make sure that the authorization header is from an account which is permitted to finalize the Auth Request through the `IAM_LOGIN_CLIENT` role.
```bash

2
docs/docs/guides/integrate/login-ui/oidc-standard.mdx
View File

@@ -80,7 +80,7 @@ Response Example:
### Perform Login
After you have initialized the OIDC flow you can implement the login.
Implement all the steps you like the user the go trough by [creating](/docs/apis/resources/session_service_v2/session-service-create-session) and [updating](/docs/apis/resources/session_service/session-service-set-session) the user-session.
Implement all the steps you like the user the go trough by [creating](/docs/apis/resources/session_service_v2/session-service-create-session) and [updating](/docs/apis/resources/session_service_v2/session-service-set-session) the user-session.
Read the following resources for more information about the different checks:
- [Username and Password](./username-password)

2
docs/docs/guides/integrate/login-ui/saml-standard.mdx
View File

@@ -77,7 +77,7 @@ Response Example:
### Perform Login
After you have initialized the SAML flow you can implement the login.
Implement all the steps you like the user to go trough by [creating](/docs/apis/resources/session_service_v2/session-service-create-session) and [updating](/docs/apis/resources/session_service/session-service-set-session) the user-session.
Implement all the steps you like the user to go trough by [creating](/docs/apis/resources/session_service_v2/session-service-create-session) and [updating](/docs/apis/resources/session_service_v2/session-service-set-session) the user-session.
Read the following resources for more information about the different checks:
- [Username and Password](./username-password)

4
docs/docs/guides/integrate/login/login-users.mdx
View File

@@ -25,7 +25,7 @@ The identity provider is not part of the original application, but a standalone
The user will authenticate using their credentials.
After successful authentication, the user will be redirected back to the original application.
If you want to read more about authenticating with OIDC, head over to our comprehensive [OpenID Connect Guide](/docs/integrate/login/oidc).
If you want to read more about authenticating with OIDC, head over to our comprehensive [OpenID Connect Guide](/docs/guides/integrate/login/oidc).
### Authenticate users with SAML
@@ -54,7 +54,7 @@ Note that SAML might not be suitable for mobile applications.
In case you want to integrate a mobile application, use OpenID Connect or our Session API.
There are more [differences between SAML and OIDC](https://zitadel.com/blog/saml-vs-oidc) that you might want to consider.
If you want to read more about authenticating with SAML, head over to our comprehensive [SAML Guide](/docs/integrate/login/saml).
If you want to read more about authenticating with SAML, head over to our comprehensive [SAML Guide](/docs/guides/integrate/login/saml).
## ZITADEL's Session API

2
docs/docs/guides/integrate/login/oidc/webkeys.md
View File

@@ -85,7 +85,7 @@ The same counts for [zitadel/oidc](https://github.com/zitadel/oidc) Go library.
## Web Key management
ZITADEL provides a resource based [web keys API](/docs/apis/resources/webkey_service_v3).
ZITADEL provides a resource based [web keys API](/docs/apis/resources/webkey_service_v2).
The API allows the creation, activation, deletion and listing of web keys.
All public keys that are stored for an instance are served on the [JWKS endpoint](#json-web-key-set).
Applications need public keys for token verification and not all applications are capable of on-demand

2
docs/docs/guides/manage/customize/branding.md
View File

@@ -46,7 +46,7 @@ If you like to trigger your settings for your applications you have different po
Send a [reserved scope](/apis/openidoauth/scopes) with your [authorization request](../../integrate/login/oidc/login-users#auth-request) 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.
You can use our [OpenID Authentication Request Playground](/oidc-playground) to learn more about how to trigger an [organization's policies and branding](/oidc-playground#organization-policies-and-branding).
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).
### 2. Setting on your Project

1
docs/docs/product/_beta-ga.mdx Normal file
View File

@@ -0,0 +1 @@
This describes the progression of features from a limited, pre-release testing phase (Beta) to their official, stable, and publicly available version (General Availability), ready for widespread use, with the specific transitions listed below.

1
docs/docs/product/_breaking-changes.mdx Normal file
View File

@@ -0,0 +1 @@
These are modifications to existing functionalities that may require users to alter their current implementation or usage to ensure continued compatibility; see the list below for specifics.

1
docs/docs/product/_deprecated.mdx Normal file
View File

@@ -0,0 +1 @@
This announces that specific existing features are being phased out and are scheduled for future removal, often because they have become outdated or are being replaced by an improved alternative; please see the deprecated items listed below.

1
docs/docs/product/_new-feature.mdx Normal file
View File

@@ -0,0 +1 @@
These introduce brand-new functionalities or capabilities, expanding the product's offerings and value to users, as detailed below.

32
docs/docs/product/_sdk_v3.mdx Normal file
View File

@@ -0,0 +1,32 @@
import NewFeature from './_new-feature.mdx';
An initial version of our Software Development Kit (SDK) will be published.
To better align our versioning with the [ZITADEL core](#zitadel-core), the SDK will be released as version 3.x.
This strategic versioning will ensure a more consistent and intuitive development experience across our entire ecosystem.
<details>
<summary>New Features</summary>
<NewFeature/>
<details>
<summary>Machine User Authentication Methods</summary>
This feature introduces robust and standardized authentication methods for your machine users, enabling secure automated access to your resources.
Choose from the following authentication methods:
- **Private Key JWT Authentication**: Enhance security by using asymmetric cryptography. A client with a registered public key can generate and sign a JSON Web Token (JWT) with its private key to authenticate.
- **Client Credentials Grant**: A simple and direct method for machine-to-machine authentication where the client confidentially provides its credentials to the authorization server in exchange for an access token.
- **Personal Access Tokens (PATs)**: Ideal for individual developers or specific scripts, PATs offer a convenient way to create long-lived, revocable tokens with specific scopes, acting as a substitute for a password.
</details>
<details>
<summary>Zitadel APIs Wrapper</summary>
This SDK provides a convenient client for interacting with the ZITADEL APIs, simplifying how you manage resources within your instance.
Currently, the client is tailored for machine-to-machine communication, enabling machine users to authenticate and manage ZITADEL resources programmatically.
Please note that this initial version is focused on API calls for automated tasks and does not yet include support for human user authentication flows like OAuth or OIDC.
</details>
</details>

63
docs/docs/product/release-cycle.mdx Normal file
View File

@@ -0,0 +1,63 @@
---
title: Release Cycle
sidebar_label: Release Cycle
---
We release a new major version of our software every three months. This predictable schedule allows us to introduce significant features and enhancements in a structured way.
This cadence provides enough time for thorough development and rigorous testing. Before each stable release, we engage with our community and customers to test and stabilize the new version. This ensures high quality and reliability. For our customers, this approach creates a clear and manageable upgrade path.
While major changes are reserved for these three-month releases, we address urgent needs by backporting smaller updates, such as critical bug and security fixes, to earlier versions. This allows us to provide essential updates without altering the predictable rhythm of our major release cycle.
![Release Cycle](/img/product/release-cycle.png)
## Preparation
The first quarter of our cycle is for Preparation and Planning, where we create the blueprint for the upcoming major release.
During this time, we define the core architecture, map out the implementation strategy, and finalize the design for the new features.
## Implementation
The second month is the Implementation and Development Phase, where our engineers build the features defined in the planning stage.
During this period, we focus on writing the code for the new enhancements.
We also integrate accepted contributions from our community and create the necessary documentation alongside the development work.
This phase concludes when the new version is feature-complete and ready to enter the testing phase.
## Release Candidate (RC)
The first month of the third quarter is for the Release Candidate (RC) and Stabilization Phase.
At the beginning of this month, we publish a Release Candidate version.
This is a feature-complete version that we believe is ready for public release, made available to our customers and community for widespread testing.
This phase is critical for ensuring the quality of the final release. We have two main objectives:
- **Community Feedback and Bug Fixing**: This is when we rely on your feedback. By testing the RC in your own environments, you help us find and fix bugs and other issues we may have missed. Your active participation is crucial for stabilizing the new version.
- **Enhanced Internal Testing**: While the community provides feedback, our internal teams conduct enhanced quality assurance. This includes in-depth feature validation, rigorous testing of upgrade paths from previous versions, and comprehensive performance and benchmark testing.
The goal of this phase is to use both community feedback and internal testing to ensure the new release is robust, bug-free, and performs well, so our customers can upgrade with confidence.
## General Availability (GA) / Stable
Following the month-long Release Candidate and Stabilization phase, we publish the official General Availability (GA) / Stable Release.
This is the final, production-ready version of our software that has been thoroughly tested by both our internal teams and the community.
This release is available to everyone, and we recommend that customers begin reviewing the official upgrade path for their production environments.
The deployment of this new major version to our cloud services also happens at this time.
**Ongoing Maintenance: Minor and Patch Releases**
Once a major version becomes stable, we provide ongoing support through back-porting. This means we carefully select and apply critical updates from our main development track to the stable release, ensuring it remains secure and reliable. These updates are delivered in two ways:
- Minor Releases: These include simple features and enhancements from the next release cycle that are safe to add, requiring no major refactoring or large database migrations.
- Patch Releases: These are focused exclusively on high-priority bug and security fixes to address critical issues promptly.
This process ensures that you can benefit from the stability of a major release while still receiving important updates and fixes in a timely manner.
## Deprecated
Each major version is actively supported for a full release cycle after its launch. This means that approximately six months after its initial stable release, a version enters its deprecation period.
Once a version is deprecated, we strongly encourage all self-hosted customers to upgrade to a newer version as soon as possible to continue receiving the latest features, improvements, and bug fixes.
For our enterprise customers, we may offer extended support by providing critical security fixes for a deprecated version beyond the standard six-month lifecycle. This extended support is evaluated on a case-by-case basis to ensure a secure and manageable transition for large-scale deployments.

714
docs/docs/product/roadmap.mdx Normal file
View File

@@ -0,0 +1,714 @@
---
title: Zitadel Release Versions and Roadmap
sidebar_label: Release Versions and Roadmap
---
import NewFeature from './_new-feature.mdx';
import BreakingChanges from './_breaking-changes.mdx';
import Deprecated from './_deprecated.mdx';
import BetaToGA from './_beta-ga.mdx';
import SDKv3 from './_sdk_v3.mdx';
## Timeline and Overview
<table id="zitadel-versions">
<thead>
<tr id="zitadel-versions-year">
<th scope="col"></th>
<th scope="col" colSpan={12}>2025</th>
<th scope="col" colSpan={12}>2026</th>
</tr>
<tr>
<th scope="col"></th>
<th scope="col" colSpan={3}>Q1</th>
<th scope="col" colSpan={3}>Q2</th>
<th scope="col" colSpan={3}>Q3</th>
<th scope="col" colSpan={3}>Q4</th>
<th scope="col" colSpan={3}>Q1</th>
<th scope="col" colSpan={3}>Q2</th>
<th scope="col" colSpan={3}>Q3</th>
<th scope="col" colSpan={3}>Q4</th>
</tr>
<tr>
<th scope="col"></th>
<th scope="col">Jan</th>
<th scope="col">Feb</th>
<th scope="col">Mar</th>
<th scope="col">Apr</th>
<th scope="col">May</th>
<th scope="col">Jun</th>
<th scope="col">Jul</th>
<th scope="col">Aug</th>
<th scope="col">Sep</th>
<th scope="col">Oct</th>
<th scope="col">Nov</th>
<th scope="col">Dec</th>
<th scope="col">Jan</th>
<th scope="col">Feb</th>
<th scope="col">Mar</th>
<th scope="col">Apr</th>
<th scope="col">May</th>
<th scope="col">Jun</th>
<th scope="col">Jul</th>
<th scope="col">Aug</th>
<th scope="col">Sep</th>
<th scope="col">Oct</th>
<th scope="col">Nov</th>
<th scope="col">Dec</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan={25}>Zitadel Versions</td>
</tr>
<tr>
<th scope="row">[v2.x](/docs/product/roadmap#v2x)</th>
<td colspan={6} class="release-stable">GA / Stable </td>
<td colSpan={3} class="release-deprecated">Deprecated</td>
<td colSpan={16}></td>
</tr>
<tr>
<th scope="row">[v3.x](/docs/product/roadmap#v3x)</th>
<td colspan={3} class="release-impl">Implementation</td>
<td class="release-rc">RC</td>
<td colspan={5} class="release-stable">GA / Stable </td>
<td colSpan={3} class="release-deprecated">Deprecated</td>
<td colSpan={12}></td>
</tr>
<tr>
<th scope="row">[v4.x](/docs/product/roadmap#v4x)</th>
<td colSpan={3}></td>
<td colSpan={3} class="release-impl">Implementation</td>
<td class="release-rc">RC</td>
<td colspan={5} class="release-stable">GA / Stable </td>
<td colSpan={3} class="release-deprecated">Deprecated</td>
<td colSpan={9}></td>
</tr>
<tr>
<th scope="row">[v5.x](/docs/product/roadmap#v5x)</th><td colSpan={3}></td>
<td colSpan={3}></td>
<td colSpan={3} class="release-impl">Implementation</td>
<td class="release-rc">RC</td>
<td colspan={5} class="release-stable">GA / Stable </td>
<td colSpan={3} class="release-deprecated">Deprecated</td>
<td colSpan={6}></td>
</tr>
</tbody>
</table>
For more detailed description about the different stages and the release cycle check out the following Page: [Release Cycle](/docs/product/release-cycle)
<table id="zitadel-versions">
<thead>
<tr>
<th scope="col">25-Q1</th>
<th scope="col">25-Q2</th>
<th scope="col">25-Q3</th>
<th scope="col">25-Q4</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan={4}>Zitadel Core</td>
</tr>
<tr>
<td scope="row">
[v2.x](/docs/product/roadmap#v2x)
</td>
<td scope="row">
[v3.x](/docs/product/roadmap#v3x)
<ul>
<li>
Actions V2
</li>
<li>
Removed CockroachDB Support
</li>
<li>
License Change
</li>
<li>
Login v2
<ul>
<li>
Initial Release
</li>
<li>
All standard authentication methods
</li>
<li>
OIDC & SAML
</li>
</ul>
</li>
</ul>
</td>
<td scope="row">
[v4.x](/docs/product/roadmap#v4x)
<ul>
<li>Resource API</li>
<li>
Login v2 as default
<ul>
<li>
Device Authorization Flow
</li>
<li>
LDAP IDP
</li>
<li>
JWT IDP
</li>
<li>
Custom Login UI Texts
</li>
</ul>
</li>
</ul>
</td>
<td scope="row">
[v5.x](/docs/product/roadmap#v5x)
<ul>
<li>Analytics</li>
<li>User Groups</li>
<li>User Uniqueness on Instance Level</li>
<li>Remove Required Fields from User</li>
</ul>
</td>
</tr>
<tr>
<td colspan={4}>Zitadel SDKs</td>
</tr>
<tr>
<td scope="row">
</td>
<td scope="row">
</td>
<td scope="row">
<ul>
<li>
[Initial Version of PHP SDK](/docs/product/roadmap#v3x-1)
</li>
<li>
[Initial Version of Java SDK](/docs/product/roadmap#v3x-2)
</li>
<li>
[Initial Version of Ruby SDK](/docs/product/roadmap#v3x-3)
</li>
<li>
[Initial Version of Python SDK](/docs/product/roadmap#v3x-4)
</li>
</ul>
</td>
<td scope="row">
</td>
</tr>
</tbody>
</table>
## Zitadel Core
Check out all [Zitadel Release Versions](https://github.com/zitadel/zitadel/releases)
### v2.x
**Current State**: General Availability / Stable
**Release**: [v2.x](https://github.com/zitadel/zitadel/releases?q=v2.&expanded=true)
In Zitadel versions 2.x and earlier, new releases were deployed with a minimum frequency of every two weeks.
This practice resulted in a significant number of individual versions.
To review the features and bug fixes for these releases, please consult the linked release information provided above.
### v3.x
ZITADEL v3 is here, bringing key changes designed to empower your identity management experience.
This release transitions our licensing to AGPLv3, reinforcing our commitment to open and collaborative development.
We've streamlined our database support by removing CockroachDB.
Excitingly, v3 introduces the foundational elements for Actions V2, opening up a world of possibilities for tailoring and extending ZITADEL to perfectly fit your unique use cases.
**Current State**: General Availability / Stable
**Release**: [v3.x](https://github.com/zitadel/zitadel/releases?q=v3.&expanded=true)
**Blog**: [Zitadel v3: AGPL License, Streamlined Releases, and Platform Updates](https://zitadel.com/blog/zitadel-v3-announcement)
<details>
<summary>New Features</summary>
<NewFeature/>
<details>
<summary>Actions V2</summary>
Zitadel Actions V2 empowers you to customize Zitadel's workflows by executing your own logic at specific points. You define external Endpoints containing your code and configure Targets and Executions within Zitadel to trigger them based on various conditions and events.
Why we built it: To provide greater flexibility and control, allowing you to implement custom business rules, automate tasks, enrich user data, control access, and integrate with other systems seamlessly. Actions V2 enables you to tailor Zitadel precisely to your unique needs.
Read more in our [documentation](https://zitadel.com/docs/concepts/features/actions_v2)
</details>
<details>
<summary>License Change Apache 2.0 to AGPL3</summary>
Zitadel is switching to the AGPL 3.0 license to ensure the project's sustainability and encourage community contributions from commercial users, while keeping the core free and open source.
Read more about our [decision](https://zitadel.com/blog/apache-to-agpl)
</details>
</details>
<details>
<summary>Breaking Changes</summary>
<BreakingChanges/>
<details>
<summary>CockroachDB Support removed</summary>
After careful consideration, we have made the decision to discontinue support for CockroachDB in Zitadel v3 and beyond.
While CockroachDB is an excellent distributed SQL database, supporting multiple database backends has increased our maintenance burden and complicated our testing matrix.
Check out our [migration guide](https://zitadel.com/docs/self-hosting/manage/cli/mirror) to migrate from CockroachDB to PostgreSQL.
More details can be found [here](https://github.com/zitadel/zitadel/issues/9414)
</details>
<details>
<summary>Actions API v3 alpha removed</summary>
With the current release we have published the Actions V2 API as a beta version, and got rid of the previously published alpha API.
Check out the [new API](http://localhost:3000/docs/apis/resources/action_service_v2)
</details>
</details>
### v4.x
**Current State**: Implementation
<details>
<summary>New Features</summary>
<NewFeature/>
<details>
<summary>Resource API (v2)</summary>
We are revamping our APIs to improve the developer experience.
Currently, our use-case-based APIs are complex and inconsistent, causing confusion and slowing down integration.
To fix this, we're shifting to a resource-based approach.
This means developers will use consistent endpoints (e.g., /users) to manage resources, regardless of their own role.
This change, along with standardized naming and improved documentation, will simplify integration, accelerate development, and create a more intuitive experience for our customers and community.
Resources integrated in this release:
- Instances
- Organizations
- Projects
- Users
For more details read the [Github Issue](https://github.com/zitadel/zitadel/issues/6305)
</details>
<details>
<summary>Login V2</summary>
Our new login UI has been enhanced with additional features, bringing it to feature parity with Version 1.
<details>
<summary>Device Authorization Flow</summary>
The Device Authorization Grant is an OAuth 2.0 flow designed for devices that have limited input capabilities (like smart TVs, gaming consoles, or IoT devices) or lack a browser.
Read our docs about how to integrate your application using the [Device Authorization Flow](https://zitadel.com/docs/guides/integrate/login/oidc/device-authorization)
</details>
<details>
<summary>LDAP IDP</summary>
This feature enables users to log in using their existing LDAP (Lightweight Directory Access Protocol) credentials.
It integrates your system with an LDAP directory, allowing it to act as an Identity Provider (IdP) solely for authentication purposes.
This means users can securely access the service with their familiar LDAP username and password, streamlining the login process.
</details>
<details>
<summary>JWT IDP</summary>
This "JSON Web Token Identity Provider (JWT IdP)" feature allows you to use an existing JSON Web Token (JWT) from another system (like a Web Application Firewall managing a session) as a federated identity for authentication in new applications managed by ZITADEL.
Essentially, it enables session reuse by letting ZITADEL trust and validate a JWT issued by an external source. This allows users already authenticated in an existing system to seamlessly access new applications without re-logging in.
Read more in our docs about how to login users with [JWT IDP](https://zitadel.com/docs/guides/integrate/identity-providers/jwt_idp)
</details>
<details>
<summary>Custom Login UI Texts</summary>
This feature provides customers with the flexibility to personalize the user experience by customizing various text elements across different screens of the login UI. Administrators can modify default messages, labels, and instructions to align with their branding, provide specific guidance, or cater to unique regional or organizational needs, ensuring a more tailored and intuitive authentication process for their users.
</details>
</details>
</details>
<details>
<summary>General Availability</summary>
<BetaToGA/>
<details>
<summary>Hosted Login v2</summary>
We're officially moving our new Login UI v2 from beta to General Availability.
Starting now, it will be the default login experience for all new customers.
With this release, 8.0we are also focused on implementing previously missing features, such as device authorization and LDAP IDP support, to make the new UI fully feature-complete.
- [Hosted Login V2](http://localhost:3000/docs/guides/integrate/login/hosted-login#hosted-login-version-2-beta)
</details>
<details>
<summary>Web Keys</summary>
Web Keys in ZITADEL are used to sign and verify JSON Web Tokens (JWT).
ID tokens are created, signed and returned by ZITADEL when a OpenID connect (OIDC) or OAuth2 authorization flow completes and a user is authenticated.
Based on customer and community feedback, we've updated our key management system. You now have full manual control over key generation and rotation, instead of the previous automatic process.
Read the full description about Web Keys in our [Documentation](https://zitadel.com/docs/guides/integrate/login/oidc/webkeys).
</details>
<details>
<summary>SCIM 2.0 Server - User Resource</summary>
The Zitadel SCIM v2 service provider interface enables seamless integration of identity and access management (IAM) systems with Zitadel, following the System for Cross-domain Identity Management (SCIM) v2.0 specification.
This interface allows standardized management of IAM resources, making it easier to automate user provisioning and deprovisioning.
- [SCIM 2.0 API](https://zitadel.com/docs/apis/scim2)
- [Manage Users Guide](https://zitadel.com/docs/guides/manage/user/scim2)
</details>
<details>
<summary>Token Exchange (Impersonation)</summary>
The Token Exchange grant implements [RFC 8693, OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693) and can be used to exchange tokens to a different scope, audience or subject.
Changing the subject of an authenticated token is called impersonation or delegation.
Read more in our [Impersonation and delegation using Token Exchange](https://zitadel.com/docs/guides/integrate/token-exchange) Guide
</details>
<details>
<summary>Caches</summary>
ZITADEL supports the use of a caches to speed up the lookup of frequently needed objects.
As opposed to HTTP caches which might reside between ZITADEL and end-user applications, the cache build into ZITADEL uses active invalidation when an object gets updated.
Another difference is that HTTP caches only cache the result of a complete request and the built-in cache stores objects needed for the internal business logic.
For example, each request made to ZITADEL needs to retrieve and set instance information in middleware.
Read more about Zitadel Caches [here](https://zitadel.com/docs/self-hosting/manage/cache)
</details>
</details>
### v5.x
**Current State**: Planning
<details>
<summary>New Features</summary>
<NewFeature/>
<details>
<summary>Analytics</summary>
We provide comprehensive and insightful analytics capabilities that empower you with the information needed to understand platform usage, monitor system health, and make data-driven decisions.
<details>
<summary>Daily Active Users (DAU) & Monthly Active Users (MAU)</summary>
Administrators need to track user activity to understand platform usage and identify trends.
This feature provides basic metrics for daily and monthly active users, allowing for filtering by date range and scope (instance-wide or within a specific organization).
The metrics should ensure that each user is counted only once per day or month, respectively, regardless of how many actions they performed.
This minimal feature serves as a foundation for future expansion into more detailed analytics.
For more details track our [github issue](https://github.com/zitadel/zitadel/issues/7506).
</details>
<details>
<summary>Resource Count Metrics</summary>
To effectively manage a Zitadel instance, administrators need to understand resource utilization.
This feature provides metrics for resource counts, including organizations, users (with filtering options), projects, applications, and authorizations.
For users, we will offer filters to retrieve the total count, counts per organization, and counts by user type (human or machine).
These metrics will provide administrators with valuable insights into the scale and complexity of their Zitadel instance.
For more details track our [github issue](https://github.com/zitadel/zitadel/issues/9709).
</details>
<details>
<summary>Operational Metrics</summary>
To empower customers to better manage and optimize their Zitadel instances, we will provide access to detailed operational metrics.
This data will help customers identify potential issues, optimize performance, and ensure the stability of their deployments.
The provided data will encompass basic system information, infrastructure details, configuration settings, error reports, and the health status of various Zitadel components, accessible via a user interface or an API.
For more details track our [github issue](https://github.com/zitadel/zitadel/issues/9476).
</details>
</details>
<details>
<summary>User Groups</summary>
Administrators will be able to define groups within an organization and assign users to these groups.
More details about the feature can be found [here](https://github.com/zitadel/zitadel/issues/9702)
</details>
<details>
<summary>User Uniqueness on Organization Level</summary>
Administrators will be able to define weather users should be unique across the instance or within an organization.
This allows managing users independently and avoids conflicts due to shared user identifiers.
Example: The user with the username user@gmail.com can be created in the Organization "Customer A" and "Customer B" if uniqueness is defined on the organization level.
Stay updated on the progress and details on our [GitHub Issue](https://github.com/zitadel/zitadel/issues/9535)
</details>
<details>
<summary>Remove Required Fields</summary>
Currently, the user creation process requires several fields, such as email, first name, and last name, which can be restrictive in certain scenarios. This feature allows administrators to create users with only a username, making other fields optional.
This provides flexibility for systems that don't require complete user profiles upon initial creation for example simplified onboarding flows.
For more details check out our [GitHub Issue](https://github.com/zitadel/zitadel/issues/4386)
</details>
</details>
<details>
<summary>Feature Deprecation</summary>
<Deprecated/>
<details>
<summary>Actions V1</summary>
</details>
</details>
<details>
<summary>Breaking Changes</summary>
<BreakingChanges/>
<details>
<summary>Hosted Login v1 will be removed</summary>
</details>
<details>
<summary>Zitadel APIs v1 will be removed</summary>
</details>
</details>
### v6.x
<details>
<summary>New Features</summary>
<NewFeature/>
<details>
<summary>Basic Threat Detection Framework</summary>
This initial version of our Threat Detection Framework is designed to enhance the security of your account by identifying and challenging potentially anomalous user behavior.
When the system detects unusual activity, it will present a challenge, such as a reCAPTCHA, to verify that the user is legitimate and not a bot or malicious actor.
Security administrators will also have the ability to revoke user sessions based on the output of the threat detection model, providing a crucial tool to mitigate potential security risks in real-time.
We are beginning with a straightforward reCAPTCHA-style challenge to build and refine the core framework.
This foundational step will allow us to gather insights into how the system performs and how it can be improved.
Future iterations will build upon this groundwork to incorporate more sophisticated detection methods and a wider range of challenge and response mechanisms, ensuring an increasingly robust and intelligent security posture for all users.
More details can be found in the (GitHub Issue](https://github.com/zitadel/zitadel/issues/9707)
</details>
<details>
<summary>SCIM Outbound</summary>
Automate user provisioning to your external applications with our new SCIM Client.
This feature ensures users are automatically created in downstream systems before their first SSO login, preventing access issues and streamlining onboarding.
It also synchronizes user lifecycle events, so changes like deactivations or deletions are instantly reflected across all connected applications for consistent and secure access management.
The initial release will focus on provisioning the user resource.
More details can be found in the (GitHub Issue](https://github.com/zitadel/zitadel/issues/6601)
</details>
<details>
<summary>Analytics</summary>
We provide comprehensive and insightful analytics capabilities that empower you with the information needed to understand platform usage, monitor system health, and make data-driven decisions.
<details>
<summary>Login Insights: Successful and Failed Login Metrics</summary>
To enhance security monitoring and gain insights into user authentication patterns, administrators need access to login metrics.
This feature provides data on successful and failed login attempts, allowing for filtering by time range and level (overall instance, within a specific organization, or for a particular application).
This will enable administrators to detect suspicious login activity, analyze authentication trends, and proactively address potential security concerns.
For more details track our [GitHub issue](https://github.com/zitadel/zitadel/issues/9711).
</details>
</details>
<details>
<summary>Impersonation: External Token Exchange</summary>
This feature expands our existing impersonation capabilities to support seamless and secure integration with external, third-party applications.
Currently, our platform supports impersonation for internal use cases, allowing administrators or support staff to obtain a temporary token for an end-user to troubleshoot issues or provide assistance within applications that already use ZITADEL for authentication. (You can find more details in our [existing documentation](/docs/guides/integrate/token-exchange)).
The next evolution of this feature will focus on external applications.
This enables scenarios where a user, already authenticated in a third-party system (like their primary e-banking portal), can seamlessly access a connected application that is secured by ZITADEL without needing to log in again.
For example, a user in their e-banking app could click to open an integrated "Budget Planning" tool that relies on ZITADEL for access.
Using a secure token exchange, the budget app will grant the user a valid session on their behalf, creating a smooth, uninterrupted user experience while maintaining a high level of security.
This enhancement bridges the authentication gap between external platforms and ZITADEL-powered applications.
</details>
</details>
### Future Vision / Upcoming Features
#### Fine Grained Authorization
We're planning the future of Zitadel and fine-grained authorization is high on our list.
While Zitadel already offers strong role-based access (RBAC), we know many of you need more granular control.
**What is Fine-Grained Authorization?**
It's about moving beyond broad roles to define precise access based on:
- Attributes (ABAC): User details (department, location), resource characteristics (sensitivity), or context (time of day).
- Relationships (ReBAC): Connections between users and resources (e.g., "owner" of a document, "manager" of a team).
- Policies (PBAC): Explicit rules combining attributes and relationships.
**Why Explore This?**
Fine-grained authorization can offer:
- Tighter Security: Minimize access to only what's essential.
- Greater Flexibility: Adapt to complex and dynamic business rules.
- Easier Compliance: Meet strict regulatory demands.
- Scalable Permissions: Manage access effectively as you grow.
**We Need Your Input!** 🗣️
As we explore the best way to bring this to Zitadel, tell us:
- Your Use Cases: Where do you need more detailed access control than standard roles provide?
- Preferred Models: Are you thinking attribute-based, relationship-based, or something else?
- Integration Preferences:
- A fully integrated solution within Zitadel?
- Or integration with existing authorization vendors (e.g. openFGA, cerbos, etc.)?
Your feedback is crucial for shaping our roadmap.
🔗 Share your thoughts and needs in our [discussion forum](https://discord.com/channels/927474939156643850/1368861057669533736)
#### Threat Detection
We're taking the next step in securing your applications by exploring a new Threat Detection framework for Zitadel.
Our goal is to proactively identify and stop malicious activity in real-time.
**Our First Step: A Modern reCAPTCHA Alternative**
We will begin by building a system to detect and mitigate malicious bots, serving as a smart, privacy-focused alternative to CAPTCHA.
This initial use case will help us combat credential stuffing, spam registrations, and other automated attacks, forming the foundation of our larger framework.
**How We Envision It**
Our exploration is focused on creating an intelligent system that:
- **Analyzes Signals**: Gathers data points like IP reputation, device characteristics, and user behavior to spot suspicious activity.
- **Uses AI/**: Trains models to distinguish between legitimate users and bots, reducing friction for real users.
- **Mitigates Threats**: Enables flexible responses when a threat is detected, such as blocking the attempt, requiring MFA, or sending an alert.
**Help Us Shape the Future** 🤝
As we design this framework, we need to know:
- What are your biggest security threats today?
- What kind of automated responses (e.g., block, notification) would be most useful for you?
- What are your key privacy or compliance concerns regarding threat detection?
Your feedback will directly influence our development and ensure we build a solution that truly meets your needs.
🔗 Join the conversation and share your insights [here](https://discord.com/channels/927474939156643850/1375383775164235806)
#### The Role of AI in Zitadel
As we look to the future, we believe Artificial Intelligence will be a critical tool for enhancing both user experience and security within Zitadel.
Our vision for AI is focused on two key areas: providing intelligent, contextual assistance and building a collective defense against emerging threats.
1. **AI-Powered Support**
We want you to get fast, accurate answers to your questions without ever having to leave your workflow.
To achieve this, we are integrating an AI-powered support assistant trained on our knowledge base, including our documentation, tutorials, and community discussions.
Our rollout is planned in phases to ensure we deliver a helpful experience:
- **Phase 1 (Happening Now)**: We are currently testing a preliminary version of our AI bot within our [community channels](https://discord.com/channels/927474939156643850/1357076488825995477). This allows us to gather real-world questions and answers, refining the AI's accuracy and helpfulness based on direct feedback.
- **Phase 2 (Next Steps)**: Once we are confident in its capabilities, we will integrate this AI assistant directly into our documentation. You'll be able to ask complex questions and get immediate, well-sourced answers.
- **Phase 3 (The Ultimate Goal)**: The final step is to embed the assistant directly into the Zitadel Console/Customer Portal. Imagine getting help based on the exact context of what you're doing—whether you're configuring an action, setting up a new organization, or integrating social login.
2. **Decentralized AI for Threat Detection**
Security threats are constantly evolving.
A threat vector that targets one customer today might target another tomorrow.
We believe in the power of collective intelligence to provide proactive security for everyone.
This leads to our second major AI initiative: **decentralized model training** for our Threat Detection framework.
Here’s how it would work:
- **Collective Data, Anonymously**: Customers across our cloud and self-hosted environments experience different user behaviors and threat vectors. We plan to offer an opt-in system where anonymized, non-sensitive data (like behavioral patterns and threat signals) can be collected from participating instances.
- **Centralized Training**: This collective, anonymized data will be used to train powerful, next-generation AI security models. With a much larger and more diverse dataset, these models can learn to identify subtle and emerging threats far more effectively than a model trained on a single instance's data.
- **Shared Protection**: These constantly improving models would then be distributed to all participating Zitadel instances.
The result is a powerful security network effect. You could receive protection from a threat vector you haven't even experienced yet, simply because the system learned from an attack on another member of the community.
## Zitadel Ecosystem
### PHP SDK
GitHub Repository: [PHP SDK](https://github.com/zitadel/client-php)
#### v3.x
<SDKv3/>
### Java SDK
GitHub Repository: [Java SDK](https://github.com/zitadel/client-java)
#### v3.x
<SDKv3/>
### Ruby SDK
GitHub Repository: [Ruby SDK](https://github.com/zitadel/client-ruby)
#### v3.x
<SDKv3/>
### Python SDK
GitHub Repository: [Python SDK](https://github.com/zitadel/client-python)
#### v3.x
<SDKv3/>

15
docs/sidebars.js
View File

@@ -183,7 +183,6 @@ module.exports = {
items: [
"guides/manage/user/reg-create-user",
"guides/manage/customize/user-metadata",
"guides/manage/customize/user-schema",
"guides/manage/user/scim2",
],
},
@@ -611,6 +610,20 @@ module.exports = {
},
],
},
{
type: "category",
label: "Product Information",
collapsed: true,
items: [
"product/roadmap",
"product/release-cycle",
{
type: "link",
label: "Changelog",
href: "https://zitadel.com/changelog",
},
],
},
{
type: "category",
label: "Support",

4
docs/src/css/custom.css
View File

@@ -641,3 +641,7 @@ p strong {
.zitadel-lifecycle-deprecated {
text-decoration: line-through;
}
table#zitadel-versions td {
vertical-align: top;
}

BIN
docs/static/img/product/release-cycle.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 100 KiB