mirror of
https://github.com/andwati/zitadel.git
synced 2026-11-12 17:15:15 +00:00
docs: remove out-dated / incorrect beta labels (#11211)
# Which Problems Are Solved Some features moved from Beta to GA in V4, are still labeled as beta in the docs and APIs refer to the now deprecated beta endpoints. # How the Problems Are Solved - remove the beta labels from webkeys, login v2, actions v2 - change example calls and API reference to v2 (instead of v2beta) # Additional Changes fixed typo in the web keys title (Oauth2 -> OAuth2) # Additional Context - Organization service v2(beta) is solved in https://github.com/zitadel/zitadel/pull/11207 - relates to #10772 --------- Co-authored-by: Gayathri Vijayan <[email protected]> Co-authored-by: Copilot <[email protected]>
This commit is contained in:
Livio Spring
co-authored by
Gayathri Vijayan
Copilot
Gayathri Vijayan
Copilot
parent
8a0580b358
commit
740669a4bd
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: OpenID Connect and Oauth2 web keys
|
||||
sidebar_label: Web keys [Beta]
|
||||
title: OpenID Connect and OAuth2 web keys
|
||||
sidebar_label: Web Keys
|
||||
---
|
||||
|
||||
Web Keys in ZITADEL are used to sign and verify JSON Web Tokens (JWT).
|
||||
@@ -106,7 +106,7 @@ When the request does not contain any specific configuration,
|
||||
[RSA](#rsa) is used as default with the default options as described below:
|
||||
|
||||
```bash
|
||||
curl -L 'https://$CUSTOM-DOMAIN/v2beta/web_keys' \
|
||||
curl -L 'https://$CUSTOM-DOMAIN/v2/web_keys' \
|
||||
-H 'Content-Type: application/json' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>' \
|
||||
@@ -130,7 +130,7 @@ The RSA generator config takes two enum values.
|
||||
For example, to create a RSA web key with the size of 3072 bits and the SHA512 algorithm (RS512):
|
||||
|
||||
```bash
|
||||
curl -L 'https://$CUSTOM-DOMAIN/v2beta/web_keys' \
|
||||
curl -L 'https://$CUSTOM-DOMAIN/v2/web_keys' \
|
||||
-H 'Content-Type: application/json' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>' \
|
||||
@@ -154,7 +154,7 @@ The ECDSA generator config takes a single `curve` enum value which determines bo
|
||||
For example, to create a ECDSA web key with a P-256 curve and the SHA256 algorithm:
|
||||
|
||||
```bash
|
||||
curl -L 'https://$CUSTOM-DOMAIN/v2beta/web_keys' \
|
||||
curl -L 'https://$CUSTOM-DOMAIN/v2/web_keys' \
|
||||
-H 'Content-Type: application/json' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>' \
|
||||
@@ -178,7 +178,7 @@ Clients which support both curves must inspect `crv` header value to assert the
|
||||
For example, to create a ed25519 web key:
|
||||
|
||||
```bash
|
||||
curl -L 'https://$CUSTOM-DOMAIN/v2beta/web_keys' \
|
||||
curl -L 'https://$CUSTOM-DOMAIN/v2/web_keys' \
|
||||
-H 'Content-Type: application/json' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>' \
|
||||
@@ -228,7 +228,7 @@ This strategy aims to fulfill the following requirements:
|
||||
Users that haven't logged in / refreshed tokens with the client app for that period,
|
||||
will need to re-enter their username.
|
||||
|
||||
When the feature flag was enabled the first time, the instance got two keys with the first one activated. When this feature becomes general 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 setup the first two keys in the same way. So the initial state always looks like this:
|
||||
|
||||
| id | created | changed | state |
|
||||
| --- | ---------- | ---------- | --------------- |
|
||||
@@ -240,11 +240,11 @@ For the sake of this example we will use simplified IDs and restrict timestamps
|
||||
After one month, on 2025-02-01, we wish to activate the next available key and create a new key to be available for activation next month. This fulfills requirements 1 and 2.
|
||||
|
||||
```bash
|
||||
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2beta/web_keys/2/_activate' \
|
||||
curl -L -X POST 'https://$CUSTOM-DOMAIN/v2/web_keys/2/_activate' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>'
|
||||
|
||||
curl -L 'https://$CUSTOM-DOMAIN/v2beta/web_keys' \
|
||||
curl -L 'https://$CUSTOM-DOMAIN/v2/web_keys' \
|
||||
-H 'Content-Type: application/json' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>' \
|
||||
@@ -276,7 +276,7 @@ In addition to the activate and create calls we made on this iteration,
|
||||
we can now safely delete the oldest key, as both requirement 3 and 4 are now fulfilled:
|
||||
|
||||
```bash
|
||||
curl -L -X DELETE 'https://$CUSTOM-DOMAIN/v2beta/web_keys/1' \
|
||||
curl -L -X DELETE 'https://$CUSTOM-DOMAIN/v2/web_keys/1' \
|
||||
-H 'Accept: application/json' \
|
||||
-H 'Authorization: Bearer <TOKEN>'
|
||||
```
|
||||
|
||||
@@ -19,7 +19,7 @@ In this case please enable the Feature Flag "Use V2 Api in Console for User crea
|
||||
- **Setup authentication later for this user**: This flow might be useful if an employee starts at a later point but you already want to prepare the account. The user will not have an authentication method, before they will be able to login, they need to setup a method.
|
||||
- **Send an invitation E-Mail for authentication setup and E-Mail verification**: The user will receive an email and be able to setup an authentication method (e.g Password, Passkey, External SSO).
|
||||
- When using the [Zitadel Login V1](/docs/guides/integrate/login/hosted-login) the user will be prompted to setup a password
|
||||
- When using the [Zitadel Login V2](/docs/guides/integrate/login/hosted-login#hosted-login-version-2-beta) the user has the option to choose the authentication method (password, passkey, identity provider), based on the configuration of the organization
|
||||
- When using the [Zitadel Login V2](/docs/guides/integrate/login/hosted-login#hosted-login-version-2) the user has the option to choose the authentication method (password, passkey, identity provider), based on the configuration of the organization
|
||||
<img src="/docs/img/guides/console/setupauthmethod.png" width="680px" alt="Invite Human - Setup authentication method" />
|
||||
- **Set an initial password for the user**: The user will receive an email and be able to setup an authentication method (e.g Password, Passkey, External SSO)
|
||||
|
||||
|
||||
+3
-5
@@ -254,8 +254,8 @@ module.exports = {
|
||||
items: [
|
||||
{
|
||||
type: "link",
|
||||
href: "/docs/guides/integrate/login/hosted-login#hosted-login-version-2-beta",
|
||||
label: "Login V2 [Beta]",
|
||||
href: "/docs/guides/integrate/login/hosted-login#hosted-login-version-2",
|
||||
label: "Login V2",
|
||||
},
|
||||
],
|
||||
},
|
||||
@@ -833,9 +833,7 @@ module.exports = {
|
||||
"The version 2 of actions provide much more options to customize ZITADELs behaviour than previous action versions.\n" +
|
||||
"Also, v2 actions are available instance-wide, whereas previous actions had to be managed for each organization individually\n" +
|
||||
"ZITADEL doesn't restrict the implementation languages, tooling and runtime for v2 action executions anymore.\n" +
|
||||
"Instead, it calls external endpoints which are implemented and maintained by action v2 users.\n" +
|
||||
"\n" +
|
||||
"Please make sure to enable the `actions` feature flag on your instance to use this service and that you're running Zitadel V3.",
|
||||
"Instead, it calls external endpoints which are implemented and maintained by action v2 users."
|
||||
},
|
||||
items: sidebar_api_actions_v2,
|
||||
},
|
||||
|
||||
Reference in New Issue
Block a user