ZITADEL - Identity Infrastructure, Simplified
OIDC Playground
The OIDC Playground is for testing OpenID Authentication Requests, giving you more insight how OpenID Connect works and how you can customize ZITADEL behavior with different parameters.
An OpenID Connect (OIDC) authentication request is an OAuth 2.0 Authorization Request using additional parameters and scopes to request that the end-user be authenticated by ZITADEL.
OIDC Authorization Request
Instance URL
Your ZITADEL instance domain
Client ID
The client identifier issued to the client
Redirect URI
URI to redirect to after authorization
Response Type
codeid_tokentoken
Determines the authorization processing flow
Scope
- openid
- profile
- address
- offline_access
- urn:zitadel:iam:org:project:id:zitadel:aud
- urn:zitadel:iam:user:metadata
- urn:zitadel:iam:org:id:[organizationId]
Space-separated list of scopes
Prompt
- (none)
- login
- select_account
- create
- none
Specifies whether the authorization server prompts the end-user for reauthentication and consent
Authentication Method
- (none)
- PKCE
- Client Secret
- Basic
Client authentication method
Code Verifier
High-entropy cryptographic random string (43-128 characters)
Code Challenge
Base64url-encoded SHA256 hash of the code verifier
Generate New PKCE Pair
Login Hint
Hint about the user's identity
ID Token Hint
Previously issued ID token
Organization ID
Organization context for the request
Generated Authorization URL
https://zitadel-instance-abcdef.zitadel.cloud/oauth/v2/authorize?client_id=123456789012345678%40yourproject&redirect_uri=https%3A%2F%2Fyourapp.com%2Fauth%2Fcallback&response_type=code&scope=openid+email+profile&code_challenge=fjUScK9oE_BfeglarcKE70sPZK3O8RFFZnUjCnRPGUU&code_challenge_method=S256
Why this OIDC playground?
Currently ZITADEL requires Users (Human) to authenticate through the hosted login page. Your application should initiate a login by issuing an authentication request and redirecting the user to the login page. You can customize the behavior of ZITADEL by providing additional parameters and scopes in the request. This playground should help you to initially craft an authentication request and to explore the behavior of ZITADEL in more depth.
Request parameters explained
Not all request parameters are available in the playground. Please refer to the full documentation of the authorization endpoint.
Your Domain
The Instance Domain to your ZITADEL instance. Use the base-path, the playground will add the required path to the request.
Required Parameters
Client ID is the resource id of an application. It's the application where you want your users to login. You can find the client ID in the Console. When using organization grants, use the client ID from the origin organization.
Redirect URI must be one of the pre-configured redirect URIs for your application. You must add the redirect URI for your application; otherwise, you will receive an error.
Response Type defines whether a code, id_token, or just id_token will be returned. Most use cases will need code.
More in the documentation about required parameters.
Authentication methods
Depending on the authentication and authorization flow of your application, you might need to append some information to the authentication request.
The authentication method "(none) PKCE" is recommended for most application types. The playground appends automatically a code challenge for PKCE flows. You need to append a "Code Challenge" by providing a random Code Verifier that is being hashed and encoded in the request to the token endpoint, please see our guide for more details.
More in the documentation about authentication methods.
Additional Parameters
Prompt defines if and how the user should be prompted on login. For example:
select_account: user is prompted to select one of the existing sessions or create a new onecreate: present the register formlogin: requires the user to re-authenticatenone: user must be authenticated without interaction; an error is returned otherwise; use for silent-refresh
Login hint must be a valid logon name of a user. You can skip the account picker by providing the login hint.
There are many more additional parameters. Please refer to the documentation about additional parameters.
Standard Scopes
Used to request additional information from ZITADEL. These scopes are defined in the OpenID Connect specification. The openid scope is mandatory. Not all scopes are available in the playground. Please refer to the full documentation for the exhaustive list of available standard and reserved scopes.
Reserved Scopes
You can request additional information that is specific to ZITADEL or customize the behavior of ZITADEL by including reserved scopes. Please refer to the documentation for a full list of available reserved scopes.
Organization policies and branding
Enforce an organization's policies and branding as well as membership of the user by passing the scope urn:zitadel:iam:org:id:{id} with the required Organization ID. Please refer to the full guide on branding.
Get user metadata
Pass the scope urn:zitadel:iam:user:metadata to request a user's metadata. Please refer to the full guide on user-metadata for further details.
Access core apis
Calling the core API with the authenticated user requires that the projectID of ZITADEL is included in the audience claim. This can be achieved by adding the scope urn:zitadel:iam:org:project:id:zitadel:aud to your application's authorization request.
How to use ZITADEL in your project
Please refer to our guide on how to login users. OpenID Connect certified libraries should allow you to customize the parameters and define scopes for the authorization request. You can also continue by using one of our example applications.