mirror of
https://github.com/andwati/zitadel.git
synced 2026-11-04 21:32:15 +00:00
docs: product roadmap and zitadel versions (#9838)
# 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
@@ -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).
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user