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: Which flow or grant should I use?¶

There are a bunch of OAuth 2.0 grants and OpenID Connect Flows. Which one should I use?

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. My application performs machine-to-machine requests with an end-user context¶

The application receives requests from other clients (such as backend-for-frontends or other resource servers) as 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:

Propagate the original end user's identity
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. My application performs machine-to-machine requests without any end-user context¶

My application is not a part of any requests chain involving any end users and only performs pure machine-to-machine API requests. 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. My application needs to validate tokens in requests from consumers¶

The application receives requests from other clients or resource servers / APIs as 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.

See token validation to validate the tokens in such requests.