Skip to content

Authentication and Authorization

Introduction to OAuth 2.0 / OpenID Connect

OpenID Connect (OIDC) and OAuth 2.0 are the preferred specifications to provide end user authentication and ensure secure service-to-service communication for applications running on the platform.

In short, OpenID Connect is used to delegate end user authentication to a third party, while the OAuth 2.0 protocol can provide signed tokens for service-to-service communication.

See the concepts pages for an introduction to basic concepts and terms that are referred to throughout this documentation.

Quickstart: How do I ...?

1. Sign-in or authenticate end users

This is a usually handled by a server-side component (backend-for-frontend) that performs the authentication flow and manages the users' sessions.

1.1. Citizen-facing applications

Use the OpenID Connect Authorization Code Flow in ID-porten.

1.2. Employee-facing applications

Use the OpenID Connect Authorization Code Flow in Azure AD.

2. Perform machine-to-machine requests - with end-user contexts

The application receives requests from other clients, such as backend-for-frontends or other resource servers, whom are authenticated with Bearer tokens. These request chains are initiated by an end user.

The application performs requests to other downstream APIs on behalf of this end user. In order to maintain the zero trust principles we must acquire new tokens for each unique downstream API. The new tokens should:

  1. Propagate the original end user's identity
  2. Be scoped to the correct downstream API with the correct aud / audience claim

2.1. Citizen-facing applications

Use the OAuth 2.0 Token Exchange Grant (TokenX).

2.2. Employee-facing applications

Use the OAuth 2.0 On-Behalf-Of Grant in Azure AD.

3. Perform machine-to-machine requests - without end-user contexts

The application only performs pure machine-to-machine API requests. It is not a part of any requests chain involving any end users. Typical examples:

  • an application that consumes a Kafka topic and performs API requests based on the Kafka record
  • a daemon that performs a task periodically

3.1. Internal

Use the OAuth 2.0 Client Credentials Grant in Azure AD.

3.2. External

Use the OAuth 2.0 JWT Authorization Grant in Maskinporten.

4. Validate authenticated API consumers

The application receives requests from other clients or resource servers / APIs, whom are authenticated with Bearer tokens.

The tokens contain information about the application that performed the request. The tokens will also contain information about the original end user, if any.

Validate the tokens before granting access to the API resource.

Last update: 2023-04-25
Created: 2020-09-22