Client Types and Application Types

One advantage of OIDC over SAML is that a broader range of types of applications can be covered. This page gives an overview on different types of applications and how they should be connected to the Switch edu-ID.

Client Types

Before talking about application types, we define the client types. We distinguish two client types: confidential and public (or non-confidential). This distinction is about how the OIDC client authenticates itself during requests to the OP.

Client Type	Description	Supported Authentication	PKCE required
confidential	Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.	`client_secret_basic` `client_secret_post` `client_secret_jwt` `private_key_jwt` See client credentials for details	No (but recommended)
public	Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.	none	Yes

Client Type

Description

Supported Authentication

PKCE required

confidential

Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

client_secret_basic
client_secret_post
client_secret_jwt
private_key_jwt

See client credentials for details

No
(but recommended)

public

Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.

none

Yes

Application Types

The OIDC specification for client registration defines the application_type with the two values web and native. The application type is currently not explicitly registered for the clients.

Application Type	Description	Allowed Redirect URLs
web	A web application is any application that runs in a web browser. The client can be either confidential (in a server-based web application or by using the backend-for-frontend (BFF) pattern) or public (user-agent-based applications, e.g. SPAs)	`https://<domain>[:{port}]/{path}` `http://localhost:{port}/{path}` allowed for dev systems
native	A native application is installed locally on a device (mobile app, desktop app, CLI tool). Native apps are always public.	Claimed "https" Scheme URI Redirection (7.2) https://<domain>[:{port}]/{path} Loopback Interface Redirection (7.3) http://127.0.0.1:{port}/{path} http://[::1]:{port}/{path} http://localhost:{port}/{path} allowed, but IP literal recommended. See RFC RFC 8252 7.3 and 8.3 Private-Use URI Scheme Redirection (7.1) {reverse-order domain}:{path} (e.g. com.example.app:/oauth2redirect/example-provider)

See the different application flavors below for more details and examples.

Application flavors

We define a set of application flavors which should classify all clients and provide best practices for them. The flavor needs to be provided when registering a client in the resource registry.

Server-based web application

An application that is running on a web server. Client credentials as well as tokens can be securely stored and are not exposed. The user accesses the application via a user-agent (web browser).

User-agent-based web application with confidential backend (Backend-for-frontend pattern, BFF)

For browser-based web applications implementing the Backend for Frontend (BFF) architecture pattern, the frontend relies on a backend component to handle all OIDC responsibilities and API interactions. In this case, the backend acts as confidential client and manages the whole OIDC protocol flow in favour of the frontend. The frontend doesn’t have a direct role in the OIDC protocol flow but lets the backend do all the requests involving secrets or tokens to other components. A good depiction of this pattern can be found in this Auth0 blog post.

User-agent-based web application without confidential backend

A user-agent-based application run directly in the user-agent (web browser). These are typically single-page applications (SPA). The application code is downloaded from a web server and executed within the user-agent, usually with JavaScript. Protocol data and credentials can easily be accessed and are therefore not secure. Therefore, these applications can't perform client authentication and MUST use PKCE.

For security reasons, we recommend to always implement the Backend for Frontend (BFF) architecture pattern to avoid the security risks implied by a public client directly integrated into the user-agent-based frontend.

Native application

A native application is a public client installed and executed on the device used by the user. These are desktop and mobile applications. It is assumed that client authentication credentials could be exposed, therefore these are public clients. Short-living dynamical credentials like access tokens or refresh tokens are assumed to receive an acceptable level of protection. These applications can't perform client authentication and MUST use PKCE.

Native applications can have redirect_uris as defined in OAuth 2.0 for Native Apps (RFC8252).

For the sake of user experience, native applications can have longer refresh token lifetimes. Depending on the implementation of token storage and rotation, a refresh token can have a timeout of up to 30 days, while we allow a chain lifetime of up to 180 days. That means, if a user is not accessing the application for a month, or at latest after 180 days, any user should perform a re-authentication.

Summary

Below we provide a table of application flavors with some examples as well as best practices which each client operator should consider when configuring the details of the connection to the edu-ID OP. For more details on refresh tokens, see our token documentation.

Please let us know if you don't know how to map your application or have other use cases.

Application Flavor	Examples	Application Type	Client Type	Refresh Token Timeout	Refresh Token Chain Lifetime
Server-based web application	PHP web application Springboot web application	web	confidential	20min - 12h Recommended: 20min	12h - 7 days Recommended: 12h
User-agent-based web application with confidential backend (Backend-for-frontend pattern)	User-agent-based web application using a backend for proxying OIDC/OAuth2 requests	web	confidential	20min - 12h Recommended: 20min	12h - 7 days Recommended: 12h
User-agent-based web application without confidential backend	Single-page application implemented with e.g. Angular or React	web	public	20min - 12h Recommended: 20min	12h - 7 days Recommended: 12h
Native application	A mobile application acting itself as public client towards the OP A desktop application acting itself as public client towards the OP	native	public	7 - 30 days Recommended: 30 days	30 - 180 days Recommended: 30 days