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.

Create application

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

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

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 Recommended because it's the most secure.
	Code Use if your application needs client id and client secret
	(Private Key) JWT Key file to authorize your application. You can create keys after created the application see below
	Post Only use if you have no other possibilities. Client id and client secret in request body

Native

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 Recommended because it's the most secure.
	Implicit Only use if you have no other possibilities. The flow is objective to be removed.

API

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:

	(Private Key) JWT Key file to authorize your application. You can create keys after created the application see below
	Basic The application sends username and password

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

SAML

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.

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 also allows glob patterns in redirect URIs with the following special terms in the patterns:

Special Terms	Meaning
*	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.

Source: github.com/bmatcuk/doublestar

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.

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.

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

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.

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.

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.