Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

About Us

Jobs

Contact

Company

Read the blog

Sign up

Login

Pricing

Blog

At Zitadel, we take customer feedback and requests from our community members as the driving force for our work. Keeping that in mind today, we are happy to announce the release of Zitadel Version 4 (General Availability) that brings in Service Ping, the new resource-based API, Zitadel's self-hosted Login, and four new SDKs.

## What is Zitadel?

Zitadel is an open-source identity and access management (IAM) platform that simplifies identity infrastructure for cloud-native and modern applications, providing enterprise-grade security and multi-tenancy support with deployment flexibility and developer-first design.

## Why Zitadel?

Some key reasons why Enterprises [choose](https://zitadel.com/blog/5-reasons-to-choose-zitadel-iam) Zitadel as their IAM solution.
* Eliminate expensive infrastructure development and deployment by using the Self-hosted option.
* Built-in enterprise security features.
* Ready-made compliance controls.
* Professional support and maintenance.
* More flexible and a transparent pricing model.
* Open-source transparency.
* Better multi-tenancy support.
* More developer-friendly.
* Modern, API-first architecture.

## How often does Zitadel release software?

We release a new major version of our [software](https://zitadel.com/docs/product/release-cycle) every three months. This predictable schedule allows us to introduce significant features and enhancements in a structured way. What we are releasing today is a Generally Available release for all our customers and users.

Following the month-long Release Candidate and Stabilization phase, today we are happy to announce 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.

## What features are available with Zitadel V4?

You can find more information about the release in our [release notes](https://github.com/zitadel/zitadel/releases/tag/v4.0.0). 

The following features are now available with Zitadel Version 4 for enabling in your production environments (Zitadel Cloud and Self-Hosted):

### Service Ping
We have added [Service Ping](https://zitadel.com/docs/self-hosting/manage/service_ping) for self-hosted customers, which allows your instance(s) to send us anonymized data about their performance and usage. You can choose what info to share, from basic details like your domain and version to more advanced metrics, or turn it off entirely. This will set a foundation for future improvements like advanced analytics and predictive threat detection.

If the feature is enabled, the base information will always be sent, and it includes the following data that is sent back to us:
* Your system ID
* The currently running version of ZITADEL
* Information on all instances
* Instance Id
* Creation Date
* Domains

### Resource-based APIs
Our new resource-based APIs make it easier to manage tasks like creating users, creating instances, and managing permissions. The new set of APIs is focused on resources like users, sessions, projects, etc. Each resource has a unique ID and a set of attributes. You can manage the complete lifecycle of a resource using V2 APIs.

With the new API design, all resources have their dedicated service. This approach minimizes the impact on other parts of the business by allowing processes to run in parallel, maintaining a clear separation of tasks. Unlike the old API that required complete updates to resources, the new resource-based APIs allow for partial updates as needed.

If you are currently using V1 APIs, you can switch to V2 by following the [provided guide](https://zitadel.com/docs/apis/migration_v1_to_v2). To learn more about how resource-based implementation works, explore our API Design documentation.

We will gradually introduce the V2 APIs to ensure that all new endpoints are thoroughly tested before becoming part of our stable releases. Refer to the release notes for an overview of V2 APIs, categorized by Beta and General Availability (GA), as well as a comprehensive list of deprecated endpoints.

### New SDKs
We are pleased to announce the availability of [new](https://zitadel.com/blog/zitadel-sdks-java-python-php-ruby) SDKs for Java, Python, PHP, and Ruby! These SDKs empower your Zitadel projects by simplifying API interactions and promoting efficient development workflows. Try out our various other SDK [examples](https://zitadel.com/docs/sdk-examples/introduction) that best suit your use case.

### Hosted Login
A few months ago, we announced the [availability](https://zitadel.com/blog/custom-login) of Hosted Login V2, and now [Zitadel's Self-Hosted Login](https://zitadel.com/docs/guides/integrate/login/hosted-login#hosted-login-version-2-beta) is the default login experience for both cloud and self-hosted customers. Get started by adding a [custom login](https://zitadel.com/blog/custom-login) to your Zitadel instance.


## How can I try out and contribute to Zitadel?

Read our [documentation](https://zitadel.com/docs) and learn how you can set up, customise, and integrate authentication and authorisation into your project. If you are interested in having a direct influence on the future [roadmap](https://zitadel.com/docs/product/roadmap) of Zitadel and early access to new features, [please apply today](https://2dljbt.share-eu1.hsforms.com/242YyCzyJRP-5ceTa2h5Uaw) to become a beta tester. 

We would love to see you being a part of the Zitadel community, and you can reach us at:
	* [Discord](https://discord.com/invite/zitadel)
	* [Github](https://github.com/zitadel/zitadel/)
	
## What is Zitadel's support model?

It's important to note that [support](https://zitadel.com/docs/support/software-release-cycles-support) may differ depending on the feature, and not all features may be fully supported. We always strive to provide the best support possible for our customers and community, but we may not be able to provide immediate or comprehensive support for all features. Also, the support may differ depending on your contracts.



We are happy to announce the release of Zitadel Version 4 (General Availability) that brings in Service Ping, the new resource-based API, Zitadel's self-hosted Login, and four new SDKs.

Announcing the General Availability of Zitadel V4

This tutorial will provide you with an overview of how to use Terraform and customize the ZITADEL behavior with different parameters based on your organization's needs. 

Terraform in Identity and Access Management

Zitadel Actions offer a powerful way to extend and tailor the behavior of the Zitadel identity platform to meet the specific needs of your organization. While Zitadel provides secure, standards-compliant authentication and user management out of the box, real-world applications often require custom logic, and that’s where Actions come into play. With Actions, you can inject dynamic behavior into key identity lifecycle processes such as user login, registration, or session handling. This enables you to validate inputs, enrich user profiles, call external APIs, enforce complex business rules, or trigger automations, all without modifying the core platform.

In this guide, we’ll demonstrate how to use Zitadel Actions V2 to implement [advanced session management](https://zitadel.com/docs/guides/integrate/actions/usage) by enforcing a limit on the number of concurrent sessions a user can have. By leveraging the `/zitadel.session.v2.SessionService/CreateSession` method, we'll track active sessions in real-time and ensure users do not exceed a predefined session cap.

Whether you're building a multi-device login system or want tighter control over authentication behavior, this guide walks you through a powerful use of Zitadel’s extensibility.


## Step 1-Deploy your target’s code

**Note**-   A [self-hosted](https://zitadel.com/docs/self-hosting/deploy/overview) or [cloud](https://zitadel.com/signin) instance of Zitadel is a pre-requisite before you get started.

To deploy this code, you can utilize your existing infrastructure or opt for a free hosting service, such as Render or Vercel. This simple Express API handles webhook events from Zitadel when a new session is created. 

It performs the following steps:
* Validates the request signature using the HMAC-based signature header provided by Zitadel, ensuring the request is authentic and unmodified.
* Extracts the user ID from the incoming event payload.
* Checks the total number of active sessions for the user.
* If the user has more sessions than the allowed limit (e.g., more than 2), it:
	* Keeps only the most recent sessions.
	* Deletes the oldest ones to enforce the session limit.

This setup allows for session control and security by enforcing session limits per user. Sample code (be aware that this code may not be production-ready):

```
const express = require('express');
const morgan = require('morgan');
const axios = require("axios");
const crypto = require('crypto');
require('dotenv').config();
const app = express();
const port = 3000;
app.use(express.json({
   verify: (req, res, buf) => {
       req.rawBody = buf.toString('utf8');
   }
}));
app.use(morgan('tiny'));
app.post('/session/manage', async (req, res) => {
   // Get the webhook signature
   const signatureHeader = req.headers['zitadel-signature'];
   if (!signatureHeader) {
       console.error("Missing signature");
       return res.status(400).send('Missing signature');
   }
   // Validate the webhook signature
   const SIGNING_SECRET = process.env.SIGNING_KEY;
   const elements = signatureHeader.split(',');
   const timestamp = elements.find(e => e.startsWith('t=')).split('=')[1];
   const signature = elements.find(e => e.startsWith('v1=')).split('=')[1];
   const signedPayload = `${timestamp}.${req.rawBody}`;
   const hmac = crypto.createHmac('sha256', SIGNING_SECRET)
       .update(signedPayload)
       .digest('hex');
   const isValid = crypto.timingSafeEqual(
       Buffer.from(hmac),
       Buffer.from(signature)
   );
   if (!isValid) {
       console.error("Invalid signature");
       return res.status(400).send('Invalid signature');
   }
   // Machine User PAT
   const PAT = process.env.PAT;
   // Max. number of concurrent sessions per user
   const CS = process.env.CONCURRENT_SESSIONS;
   // Zitadel Instance URL
   const instanceURL = process.env.INSTANCE_URL;
   const body = req.body;
   // User ID of the user that just logged in
   const userID = body.request.checks.user.userId
   // Request used to query the sessions for that userID
   let data = {
       "queries": [
           {
               "userIdQuery": {
                   "id": `${userID}`
               }
           }
       ]
   };
   try {
       const response = await axios.post(`${instanceURL}/v2/sessions/search`, data, {
           headers: {
               'Content-Type': 'application/json',
               'Authorization': `Bearer ${PAT}`
           }
       });
       // Sort sessions by creation date and grab only the fields I need
       const sortedSessions = response.data.sessions.sort((a, b) => {
           return new Date(b.creationDate) - new Date(a.creationDate);
       });
       // Check if there are more than X concurrent sessions
       if (sortedSessions.length > CS) {
           // Only the X most recent sessions will remain
           const sessionsToDelete = sortedSessions.slice(CS);
           for (const session of sessionsToDelete) {
               console.log(`Deleting session ID: ${session.id}`);
               await axios.delete(`${instanceURL}/v2/sessions/${session.id}`, {
                   headers: {
                       Authorization: `Bearer ${PAT}`,
                       'Content-Type': 'application/json'
                   }
               });
           }
       }
   } catch (error) {
       console.error('Error:', error.response?.data || error.message);
   }
   res.status(200).send('OK');
});
// Start the server and listen on the specified port
app.listen(port, () => {
   console.log(`Server listening at http://localhost:${port}`);
});
```

* To run this code, you will need to set the following environment variables:

	* **`PAT`**: An IAM_OWNER Personal Access Token to call the Zitadel API.
	* **`CONCURRENT_SESSIONS`**: The maximum number of concurrent sessions per user.
	* **`INSTANCE_URL`**: Your Zitadel instance URL.
	* **`SIGNING_KEY`**=Your Target’s signing key, obtained in the next step

* You can modify this code to use another method to authenticate the service user instead of a [PAT](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users#personal-access-tokens-pats), for instance, client_credentials. You will be able to set the SIGNING_KEY after you create the target in the next step. At the time of writing this blog post, it is possible to create targets and V2 actions using the APIs directly.

**Note**: Action will be moved to General Availability with the Zitadel V4 release.


## Step 2-Create your Target
* To create a [target](https://zitadel.com/docs/apis/resources/action_service_v2/action-service-create-target), use the following cURL command:

```
curl -L -X POST '<INSTANCE_URL>/v2beta/actions/targets' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
-d '{
    "name": "<TARGET_NAME>",
    "restAsync": {
        "interruptOnError": false
    },
    "endpoint": "<TARGET_URL>",
    "timeout": "10s"
}'

```
* where these variables mean the following:

	* **`INSTANCE_URL`**: The URL where your Zitadel instance is hosted, either cloud or self hosted.
	* **`TOKEN`**: A token with Admin permissions, can be the same PAT used in the previous step.
	* **`TARGET_NAME`**: Pick a meaningful name for your Target.
	* **`TARGET_URL`**: The webhook URL that will be POSTed by Zitadel, this points to the API you deployed in the previous step.

* As a response, you will receive something like this:
```
{
   "id": "<TARGET_ID>",
   "creationDate": "2025-07-18T11:12:47.998576Z",
   "signingKey": "<SIGNING_KEY>"
}
```

* You will need the TARGET_ID in the next step, and SIGNING_KEY as the environment variable for the code you deployed in step 1.

## Step 3 - Create your Action

* To create the [Action](https://zitadel.com/docs/apis/resources/action_service_v2/action-service-set-execution), use the following cURL command:

```
curl -L -X PUT '<INSTANCE_URL>/v2beta/actions/executions' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
-d '{
    "condition": {
        "request": {
            "method": "/zitadel.session.v2.SessionService/CreateSession"
        }
    },
    "targets": ["<TARGET_ID>"]
}'
```
* where these variables mean the following:

	* **`INSTANCE_URL`**: The URL where your instance is hosted, either cloud or self-hosted.
	* **`TARGET_ID`**: The ID of the target created in the previous step.
TOKEN: A token with Admin permissions can be the same PAT used in the previous step.


## Step 4 - Test logging in with a sample user and validate the number of sessions

* To get the list of [sessions](https://zitadel.com/docs/apis/resources/session_service_v2/session-service-list-sessions) for a user, use the following cURL command:

```
curl -L -X POST '<INSTANCE_URL>/v2/sessions/search' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <TOKEN>' \
-d '{
  "queries": [
    {
      "userIdQuery": {
        "id": "<USER_ID>"
      }
    }
  ]
}'

```

**Note**- Sessions may be invalid because the session cookie expired (or cookies were deleted), therefore, the session stored by Zitadel cannot be referenced anymore by the client application (the browser). This means that those sessions cannot be used, or simply expired, but that is something that cannot be determined by Zitadel.


## Conclusion

This approach provides a simple yet effective way to manage concurrent sessions using Zitadel Actions V2. By enforcing session limits, you gain better control, enhanced security, and a foundation for more advanced session management features.To continue exploring Zitadel Actions, you could create one to get current sessions inside a custom claim in the user token, so users can manage their sessions on your application. 


## How can I try out and contribute to Zitadel?

Read our [documentation](https://zitadel.com/docs) and learn how you can set up, customise, and integrate authentication and authorisation into your project. We would love to see you being a part of the Zitadel community, and you can reach us at

-   [Discord](https://discord.com/invite/zitadel)
    
-   [Github](https://github.com/zitadel/zitadel/)
    

## Suggested reading

-   [Zitadel Getting Started](https://zitadel.com/docs/guides/start/quickstart)

In this guide, we’ll demonstrate how to use Zitadel Actions V2 to implement advanced session management by enforcing a limit on the number of concurrent sessions a user can have. 

Advanced Session Management with Zitadel Actions V2

## Introducing an OIDC Playground by Zitadel: The Fastest Way for Developers to Master Authentication

Let’s face it: authentication is rarely the part of your stack that gets developers excited. OIDC flows can feel like a black box, and when something breaks, you’re left deciphering cryptic errors, scouring docs, or waiting for support. That’s wasted engineering time and momentum.

At Zitadel, we’re obsessed with building for developers and platform engineers. That’s why we created the [OIDC Playground](https://zitadel.com/playgrounds/oidc), a hands-on, interactive tool that lets you experiment with OpenID Connect authentication requests, see how Zitadel responds, and iterate in real time. Whether you’re integrating, debugging, or just curious, this is your fast lane to understanding and control.

## What is Zitadel?

Zitadel is an open-source identity and access management (IAM) platform built for modern, cloud-native applications. We help you ship authentication and authorization quickly, securely, and at scale without having to build or maintain complex identity infrastructure. ZITADEL delivers enterprise-grade security, true multi-tenancy, flexible deployment, and a developer-first experience.

## Why Zitadel?

Enterprises choose Zitadel as their IAM solution for several key reasons:

-   Eliminate expensive infrastructure development:  Go self-hosted or cloud, and skip months of building and maintaining IAM.
-   Built-in enterprise security features: From Passekys, to one-time passwords to Single Sign-on, we've got you covered.
-   Ready-made compliance controls:  Ready-made controls help you meet regulatory requirements.
-   Professional support and maintenance: You get professional help and upkeep.
-   More flexible and a transparent pricing model:  No surprises, no opaque “enterprise” gates.
-   Open-source transparency:  Inspect, contribute, or extend no black boxes.
-   Solid multi-tenancy support: It handles millions of tenants at scale.
-   Developer-friendly:  Integrate in days, not weeks, with modern APIs and docs.
-   Modern, API-first architecture: Provides a modern, API-first approach.
    

## What is OIDC?

[OpenID Connect](https://openid.net/developers/specs/) (OIDC) is the industry standard for authentication, sitting on top of OAuth 2. It lets your apps verify users’ identities and get profile information via secure, standardized tokens (JWTs). OIDC is enabled when a client includes the `openid` scope in an authorization request. The result? Your app receives an ID Token, a JWT containing “claims” about the user (like name, email, or custom attributes).

## What is the OIDC Playground from Zitadel?

An OIDC (OpenID Connect) playground is useful for developers, security engineers, and testers to experiment and debug OIDC flows in a controlled environment. The playground can be helpful in many different ways:

#### Learning and Experimentation

-   Understand how OIDC works by crafting an authentication request.
-   An OIDC authentication request is a standardized way for a relying party (an application or website) to request a user's identity information from an OpenID provider.
    

#### Debugging and Development

-   Easily modify parameters like client_id, scope, redirect_uri, response_type, etc., to observe how different parameters change the behavior
-   Useful for debugging issues like:
	-   Invalid redirect URIs
	-   Token decoding problems    
	-  	Scopes not returned as expected
    
## Pre-Requisites

-   A [self-hosted](https://zitadel.com/docs/self-hosting/deploy/overview) or [cloud](https://zitadel.com/signin) instance of Zitadel.
-   Create a new [Project](https://zitadel.com/docs/guides/manage/console/projects) and create a new [User.](https://zitadel.com/docs/guides/manage/user/reg-create-user)
-   Create a client.
-   Take a note of the issuer URL, which can be obtained by logging into your Zitadel instance.
-   Click Projects > Select the respective project > Select the respective application > Click URLs
    

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXdhV734K4DL9ckcOlx-U25xXpWTrOS7WuT-FnTqI5P9Xj5x36fXF0iPrDd7vybYLHhenwXUzeMrOLQfMh2jieI4w1gFkIwvknsUm_EbyieUujmAr8WM_J1bluWrH6_P3FbUfwxLmg?key=bgcsq8E2ip6wVk3nVSJgBA)

-   Web App (Optional)- We are using the OIDC debugger in this tutorial    
-   To enable users to register with a local account (username/password), you need to enable the "register allowed" setting in the login behavior settings within ZITADEL.
-   When enabled, a registration button will appear on the login page, allowing users to create new accounts. You can specify the organization users are registered to during the registration process by including the organization scope in the authorization request.
    

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXeV3Vr_efJwLQgLk1R1Atp83-AOH7NRtAGdNmvpSCMqmdsgw0R3Qn3ymhEmyl3NOAxEY0dLt90BQERdlcuz-Pj9vkFjc4qE-fYdlINSqBear_lnLiw5KA_gWiRdYYQBL64DVcEkGw?key=bgcsq8E2ip6wVk3nVSJgBA)

## How can you get started with the OIDC playground from Zitadel?

This playground will help you craft an authentication request initially and explore the behavior of Zitadel in more depth.

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXe_qtGjVMPdJGUX0r6U9PfpA-1mYWUcc5nmc70Z16RQMgul5IwvAUc4xmWIm5SsCNSuJBhnOOV14tCVWaX8mLMRiVADUBok81Te3suGh1HEtBf-6Sw0lpMH36-4pu5r9MUSBcmkHg?key=bgcsq8E2ip6wVk3nVSJgBA)

### Required Parameters

-   Your Domain- The Instance Domain for your Zitadel instance.
-   Example: [https://test1-zitadel-tuyhqf.us1.zitadel.cloud](https://test1-zitadel-tuyhqf.us1.zitadel.cloud)
-   Client ID is the unique identifier assigned to a client application of an application. It's the application where you want your users to log in. You can find the client ID in the Console. Click> Project> Choose your respective project where the application has been created> Click on the Application > Click Configuration
    

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXcsEc7lv5ssX6JrOp4t4o8K5PfI7CtNiT51j91LYJoKCWkRjB-0mxSag6xU_Saj3TbzHFck4ZSeb0s9jlUK0Assfa50azZ93uNgYQYg-SRzXkG7NlkLMjwtEDlm-TlmSUQe7k1R?key=bgcsq8E2ip6wVk3nVSJgBA)
-   Redirect URI is one of the pre-configured redirect URIs for your application.    
-   Example- [http://localhost:3000/callback](http://localhost:3000/callback)
-   Response Type defines whether a code, id_token token or just id_token will be returned. Most use cases will need code. This tells the authorization server which grant to execute. When you choose code, you will use the Authorization Code grant (recommended).
    

### Authentication methods

-   Depending on the authentication and authorization flow of your application, you might need to append some information to the authentication request.
-   Authentication method "(none) PKCE" is recommended for most application types. The playground automatically appends a code challenge for PKCE flows.

### Additional Parameters

Prompt defines if and how the user should be prompted on login. For example:

-   login: requires the user to re-authenticate.

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXdCZRyrhfKtDmnPxtbA32k4WdnhqQKFVVMXitM8c0Yi5MobPNQEf1wZ3BfNopM81sm1o2-j0cQLL8_RcG9eK6ZJckuI2M3vTwhAPA3xakzPGKql4l92nAJZuguMyyUhZXcfj60s0w?key=bgcsq8E2ip6wVk3nVSJgBA)

-   none: user must be authenticated without interaction, an error is returned otherwise; use for silent-refresh.

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXfxa95i2sLLSEwG3jo9yZ87kVib2pzjrCUsvDR98JicKTYLs5iT0R1mkKNOmeWXKBglBjApUwjdljnuIAArcY_tIWOM5ViZ_FN_13qPRYb5QyDIOy3kB9gqG5q_kapmiNDsANYj?key=bgcsq8E2ip6wVk3nVSJgBA)

-   create: present the registration form.

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXc45ZwhvspV3RQR6kBw6Xz0t4ZOjWYxxdNx0qNcVK706bTk2652ugrCkD7hbtfFAHp6_ow1bm6lGnfCEOzj0Tvake5oSyJH0jibDbwgDUIpgQlcUHG2J6oYbGQiGU5aR1km12U6?key=bgcsq8E2ip6wVk3nVSJgBA)

-   The user would be prompted to register.

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXeJA9qh-d1lOVVkYXKC0FNnq9IbiudTAJ2hG6iaSMBW-E4yKJ-5OSzYcNh_Ads232F0aT1S1JtMPQ2WVyh60KsIA1BVLS6GNE1oNZyqtBBfdAlHAD7ZuoCrU3XoU-dqt3kBrZM9Xw?key=bgcsq8E2ip6wVk3nVSJgBA)

-   select_account: The user is prompted to select one of the existing sessions or create a new one.
-   Using the login hint- The Login hint must be a valid logon name of a user. You can skip the account picker by providing the Login hint.

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXcQQQnfItiygoETRxHjpSQNnb4sYW8Yy7Xk1YxpS_9Szpwy_D_qAnDgGGF6pdPJXzYR-KXSxwSdnJhmafLd4frF5Pmz_am5Lj_V0Ov5ultILOPt0nzdM57-MAxXebnHv-rOhECe3g?key=bgcsq8E2ip6wVk3nVSJgBA)

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXf1FyQMwAlXAhSoxvLtZcwiep6xXjs3obrJmPJgvjYKeo0o0LYzzjNlcPYH9AnJ7Tyiz2Wv1UM4pBcjzYi8xToknEQ_ujDpEc6HU4r-KMrEswU9KwUTY51RT3mkKW10j48Iqnd5bQ?key=bgcsq8E2ip6wVk3nVSJgBA)

-   Without using the login hint- The user is prompted to select the respective user.
   
![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXct1CUvLP2aLtolMAftm2ExJWRdRTVI7UTFCusnX1PomxgmVXrNfWdbEDdznQWY7MXbDSd_hBBGTIZHk51Db_CYOQEw6Tdw-aDQiWpFPI4Kkn9YlJD-Uk2btsMn36rT1fJDcGp0Ag?key=bgcsq8E2ip6wVk3nVSJgBA)

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXc1C63ZZRAeTYMG78nYvA5ajzgNFPYGX_9o_CNsmqNc9RwlwEs5gBRpGl5-oq6UBy53NYjHTMO9DQ48guZXOpIzzozKPEvNPFNp48Jy4lffaSodsU7hLkeSvng_H2zXaezUikjr?key=bgcsq8E2ip6wVk3nVSJgBA)

## Conclusion

Hopefully, this tutorial gave you a good overview of how you can use the OIDC playground for testing OpenID Authentication Requests and can customize Zitadel behavior with different parameters based on your organization's needs. We encourage you to [explore Zitadel](https://zitadel.com/signin) on the cloud or self-hosted environment(s). If you want to learn more before starting, request a demo today. Click the [button](https://zitadel.com/discoverycall)to get in touch!

If you’re building in the Bay Area, or anywhere developers value speed, clarity, and control, the Zitadel OIDC Playground is your shortcut to robust, modern authentication without the guesswork.

## How can I try out and contribute to Zitadel?

Read our [documentation](https://zitadel.com/docs) and learn how you can set up, customise, and integrate authentication and authorisation into your project. We would love to see you being a part of the Zitadel community, and you can reach us at

-   [Discord](https://discord.com/invite/zitadel)
    
-   [Github](https://github.com/zitadel/zitadel/)
    

## Suggested reading

-   [Zitadel Getting Started](https://zitadel.com/docs/guides/start/quickstart)
    
-   [OIDC and Zitadel](https://zitadel.com/blog/secure-logins-with-zitadel-part-1)
    
-   [Securing Applications with OIDC and Zitadel](https://zitadel.com/blog/secure-logins-with-zitadel-part-2)

At Zitadel, we’re obsessed with building for developers and platform engineers. That’s why we created the OIDC Playground, a hands-on, interactive tool that lets you experiment with OpenID Connect authentication requests, see how Zitadel responds, and iterate in real time. Whether you’re integrating, debugging, or just curious, this is your fast lane to understanding and control.

Introducing an OIDC Playground by Zitadel: The Fastest Way for Developers to Master Authentication

At Zitadel we take customer feedback and requests from our community members as the driving force for our work. Keeping that in mind today, we are happy to announce the release of Zitadel Version 4 (Release Candidate) that brings in Service Ping, the new resource-based API, Zitadel's custom login and four new SDK's.
## What is Zitadel?
Zitadel is an open-source identity and access management (IAM) platform that simplifies identity infrastructure for cloud-native and modern applications, providing enterprise-grade security and multi-tenancy support with deployment flexibility and developer-first design.
## Why Zitadel?
Some key reasons why Enterprises [choose](https://zitadel.com/blog/5-reasons-to-choose-zitadel-iam) Zitadel as their IAM solution.

 - Eliminate expensive infrastructure development and deployment by using the Self-hosted option.
 - Built-in enterprise security features.
 - Ready-made compliance controls.
 - Professional support and maintenance.
 - More flexible and a transparent pricing model.
 - Open-source transparency.
 - Better multi-tenancy support.
 - More developer-friendly.
 - Modern, API-first architecture.
## How often does Zitadel release software?
We release a new major version of our [software](https://zitadel.com/docs/product/release-cycle) every three months. This predictable schedule allows us to introduce significant features and enhancements in a structured way.

What we are releasing today is a release candidate. 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.
 ## What features are available with Zitadel V4 RC?
**Zitadel V4 RC Release Notes**
- You can find more information about the release in our [release notes](https://github.com/zitadel/zitadel/releases/tag/v4.0.0-rc.1).

The following features are now available with Zitadel Version 4 Release Candidate (RC) for testing in your non-production environments (Zitadel cloud or Self-Hosted). 

**Service Ping**
- We have added Service Ping for self-hosted customers which lets your instance(s) send us anonymised data about how it's performing and how you are using it. You can choose what info to share, from basic details like your domain and version to more advanced metrics, or turn it off entirely. This will set a foundation for future improvements like advanced analytics and predictive threat detection.
- If the feature is enabled, the base information will always be sent and it includes the following data that is sent back to us:
	- Your systemID
	- The currently run version of ZITADEL
	- Information on all instances
	  - Instance Id
	  - Creation Date
	  - Domains

**Resource-based API**
- Our new [resource-based API](https://zitadel.com/docs/apis/v2) offers flexibility when performing resource management tasks (i.e. user creation, instance creation, permission management) that echo across the Zitadel platform.
- The API and its services use a resource-oriented design. This means that the API is designed around resources, which are the key entities in the system. Each resource has a unique identifier and a set of properties that describe the resource. The entire lifecycle of a resource can be managed using the API. 
- With this feature, all resources now have their own supporting service. This limits impact to other aspects of the business as it runs in parallel to produce a separation of concern. Whereas the [old API](https://zitadel.com/docs/apis/services) required you to have the full scope to update the resource, this new resource-based API no longer hinders such workflows as you can partially update resources as you need.
- You can [migrate](https://zitadel.com/docs/apis/migration_v1_to_v2) from v1 to v2 API's as well.
- If you are interested in applying this to your own resource-based implementation, read more [here](https://github.com/zitadel/zitadel/blob/main/API_DESIGN.md) about our API Design.
- We would be interested in getting your feedback as we look forward to provide [connectRPC](https://connectrpc.com/) support with and without the use of SDK's going forward.

![Resource Based](https://cdn.sanity.io/images/y3uu7rkl/production/a3226f95d6668c30c4d357f11f4963e9cf3bcc84-1200x630.png)

**New SDK's**
- We are pleased to announce the availability of [new](https://zitadel.com/blog/zitadel-sdks-java-python-php-ruby) SDK's for Java, Python, PHP, and Ruby! These SDKs empower your Zitadel projects by simplifying API interactions and promoting efficient development workflows.
- Try out our various other SDK [examples](https://zitadel.com/docs/sdk-examples/introduction) that best fit suit your use-case.

**Customer Login**
- Few months ago we had announced the [availability](https://zitadel.com/blog/custom-login) of Custom Login
and now [Zitadel's Custom Login](https://zitadel.com/docs/guides/integrate/login/hosted-login#hosted-login-version-2-beta) is the default login experience for both cloud and self-hosted customers to benefit from the added flexibility and customisation. Get started by adding a [custom login](https://zitadel.com/blog/custom-login) to your Zitadel instance.

## Where can I find more information about Zitadel's roadmap?
### Some Exciting News
We are also excited to announce a brand new Beta Tester program. This program will provide you access to the upcoming features, designs, and prototypes before they are ready for general release. You can test them and provide direct feedback and/or input to the Zitadel Product Team. If you are interested in having a direct influence on the future [roadmap](https://zitadel.com/docs/product/roadmap) of Zitadel, [please apply today](https://2dljbt.share-eu1.hsforms.com/242YyCzyJRP-5ceTa2h5Uaw).
## How can I try out and contribute to Zitadel?
- Read our [documentation](https://zitadel.com/docs) and learn how you can setup, customise, and integrate authentication and authorisation to your project.

- We would love to see you being a part of the Zitadel community and you can reach us on
	- [Discord](https://discord.com/invite/zitadel)
	- [Github](https://github.com/zitadel/zitadel/)
## What is Zitadel's support model?
It's important to note that [support](https://zitadel.com/docs/support/software-release-cycles-support) may differ depending on the feature, and not all features may be fully supported. We always strive to provide the best support possible for our customers and community, but we may not be able to provide immediate or comprehensive support for all features. Also the support may differ depending on your contracts.

Announcing the release of Zitadel Version 4 (Release Candidate) that brings in Service Ping, the new resource-based API, Zitadel's custom login, and four new SDKs.

Available Now: Zitadel Version 4 Release Candidate

All posts/ #zitadel