Authentication and Authorization¶
Introduction to OAuth 2.0 / OpenID Connect¶
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¶
1.2. Employee-facing applications¶
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:
- 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¶
2.2. Employee-facing applications¶
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
4. Validate authenticated API consumers¶
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.