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

  1. Introducing an OIDC Playground by Zitadel: The Fastest Way for Developers to Master Authentication
  2. What is Zitadel?
  3. Why Zitadel?
  4. What is OIDC?
  5. What is the OIDC Playground from Zitadel?
    1. Learning and Experimentation
    2. Debugging and Development
  6. Pre-Requisites
  7. How can you get started with the OIDC playground from Zitadel?
    1. Required Parameters
    2. Authentication methods
    3. Additional Parameters
  8. Conclusion
  9. How can I try out and contribute to Zitadel?
  10. Suggested reading

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, 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 (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 or cloud instance of Zitadel.
  • Create a new Project and create a new 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

  • 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.

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.

Required Parameters

  • Your Domain- The Instance Domain for your ZITADEL instance.
  • Example: https://amit-tme-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

  • Redirect URI is one of the pre-configured redirect URIs for your application.
  • Example- 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.

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

  • create: present the registration form.

  • The user would be prompted to register.

  • 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.

  • Without using the login hint- The user is prompted to select the respective user.

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 on the cloud or self-hosted environment(s). If you want to learn more before starting, request a demo today. Click the buttonto 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 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

Suggested reading

Liked it? Share it!