zitadel/docs/docs/guides/manage/console/applications.mdx

---
title: Applications
---

import ThemedImage from "@theme/ThemedImage";

import AuthType from "../../integrate/application/_auth-type.mdx";
import ReviewConfig from "../../integrate/application/_review-config.mdx";

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

<img
  alt="Granted project"
  src="/docs/img/guides/console/applications.png"
  width="750px"
/>

<!-- TODO: oidc vs saml --->

## Create application

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

<img
  alt="Add application"
  src="/docs/img/guides/console/addapplication.png"
  width="120px"
/>

## Application Types

At the moment ZITADEL offers four client types:

- [**Web**](#web) (Server-side web applications such as java, .net, ...)
- [**Native**](#native) (native, mobile or desktop applications)
- [**User Agent**](#user-agent) (single page applications / SPA, generally JavaScript executed in the browser)
- [**API**](#api) (OAuth Resource Server)

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](../../integrate/oauth-recommended-flows.md#different-client-profiles).

### 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:

<AuthType appType="web" />

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

<AuthType appType="native" />

### 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](../../../examples/login/angular) or [React](../../../examples/login/react)

Following **authentication methods** can be used:

<AuthType appType="user-agent" />

### 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:

<AuthType appType="api" />

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

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

<img
  alt="Redirect URIs"
  src="/docs/img/guides/console/redirecturis.png"
  width="600px"
/>

In order to **develop locally** and due to the fact that any ZITADEL configuration is secure by default, ZITADEL requires you enable **dev mode** if you want to redirect users to URIs other than https://.

## Review Configuration

<ReviewConfig authType="code" />

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

<img
  alt="Redirect URIs"
  src="/docs/img/guides/console/application.png"
  width="800px"
/>

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

<img
  alt="OIDC Compliance"
  src="/docs/img/guides/console/oidc-compliance.png"
  width="600px"
/>

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

<img
  alt="Token settings"
  src="/docs/img/guides/console/app-token-settings.png"
  width="600px"
/>

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

<img
  alt="Redirect URIs"
  src="/docs/img/guides/console/redirect-uris.png"
  width="500px"
/>

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

<img
  alt="Additional origins"
  src="/docs/img/guides/console/additional-origins.png"
  width="500px"
/>