Skip to main content

ZITADEL Applications

What is an application?​

Applications are the entry point to your project. Users either login into one of your clients and interact with them directly or use one of your APIs. All applications share the roles and authorizations of their project.

To access your applications, navigate to your project and select your application.

Granted project

Create application​

To add an application to your project, click on the add button and select your application type.

Add application

Application Types​

At the moment ZITADEL offers four client types:

  • Web (Server-side web applications such as java, .net, ...)
  • Native (native, mobile or desktop applications)
  • User Agent (single page applications / SPA, generally JavaScript executed in the browser)
  • API (OAuth Resource Server)
  • SAML

The first three options (Web, Native and User Agent) require user interaction, the fourth option (API) has no direct user-interaction. Depending on the app type, there are small differences in the possible settings.

To get a good understanding about user profiles and recommended flows, read the following guide.


Web applications are server side rendered applications users interact with. For example if you develop an application using Thymeleaf in Java or Razor in .NET or want to enable SSO in Gitlab.

Typical React or Angular apps are not a Web applications in this case. A NextJS on the contrary would be because it allows you to implement server side code.

Following authentication types can be used:

pkce preview


Recommended because it's the most secure.

code preview


Use if your application needs client id and client secret

jwt preview

(Private Key) JWT

Key file to authorize your application. You can create keys after created the application see below

post preview


Only use if you have no other possibilities. Client id and client secret in request body


Native Applications installed on a thin client. For example on a smartphone or computer. This can for example be Android and iOS Applications.

These applications uses the Key file generated by ZITADEL to authenticate.

Native only supports code authentication type, that's why you don't have to select any

User Agent​

User Agent Applications that are executed in a web browser, for example single page applications executed in the browser developed with JavaScript frameworks like Angular or React

Following authentication methods can be used:

pkce preview


Recommended because it's the most secure.

Implicit preview


Only use if you have no other possibilities. The flow is objective to be removed.


These are Applications without human interaction. These applications are accessed by other applications, so called machine to machine communication.

Following authentication types can be used:

jwt preview

(Private Key) JWT

Key file to authorize your application. You can create keys after created the application see below

Basic preview


The application sends username and password

After selecting your Apps Type and Authentication Method, you may need to specify redirect URIs.


If your application doesn't support the OIDC standard, but SAML this is the right application type to choose. SAML is an open standard used for authentication based on XML.

After entering a name and choosing the application type "SAML", you will get to the SAML configuration screen.

You can either add a link to a SAML metadata file or upload it directly. SAML metadata is an XML document which contains information necessary for interaction with SAML-enabled identity or service providers.

You can find some example configurations for SAML 2.0 in our integrate services guides

Redirect URIs​

App Types with User interaction (Web, Native and User Agent) require redirect URIs. Those redirects URIs are used to redirect the user back to your application on successful login.

These URIs are defined in your application code and are checked by ZITADEL if they correspond to your applications configuration. Redirect URIs are checked during the login process. Native applications can use a different protocol than http or https in order to redirect your user.

Redirect URIs

Development mode​

In order to develop locally, or you want to redirect users to any other protocol than https://, you must enable Development mode. When disabled only https is allowed, as ZITADEL's configuration is secure by default.

Development mode

Development mode also allows glob patterns in redirect URIs with the following special terms in the patterns:

Special TermsMeaning
*matches any sequence of non-path-separators
/**/matches zero or more directories
?matches any single non-path-separator character
[class]matches any single non-path-separator character against a class of characters see "character classes"
{alt1,...}matches a sequence of characters if one of the comma-separated alternatives matches

Special character can be escaped with a backslash (\).

Double stars (**) should appear surrounded by a path separators such as /**/. A mid-pattern double star (**) behaves like bash's glob star option: a pattern such as path/to/**.txt would return the same results as path/to/*.txt. The pattern you're looking for is path/to/**/*.txt.


When IPv6 URIs are used as redirects in development mode, square brackets must be escaped as they are also Special Terms for globs. http://\[::1\]:80

Review Configuration​

The last page of the stepper shows a summary of what will be created. After you have reviewed the configuration you can create the application.

Client information

Please make sure to safe the client id and secret for later use in the application.

client infos

Application settings​

After creating the application, you can still change its configuration if you for example need a offline_access support (Refresh token). You can easily change your authentication method via the colored toggle on top or directly change configuration via the input and dropdown fields.

Note: Changing application type is not possible. In this case you have to create a new application.

Redirect URIs

On the top of the page you can check if your application is OIDC compliant. Tasks for completion are shown in the field.

OIDC Compliance

Token settings​

In the token settings you can change the type from Bearer Token to JWT, and check some settings whether you need user roles and user information in the ID Token or not. On the bottom you can optionally set a ClockSkew time which is added to the expiration time of the issued token.

Token settings

Redirect settings​

Like on creation, you can modify you redirect settings here. Note that for local development you most likely have to enable development mode, as redirects to http:// are otherwise blocked. On Native Apps you can also skip the Login Success Page.

Redirect URIs

Additional origins​

If you need to allow additional origins which should NOT be used as redirect you can specify them in the Additional origins section.

Additional origins