Quarkus Security Concepts

HTTP Basic Authentication is one of the least resource-demanding techniques that enforce access controls to the Web resources. It uses fields in the HTTP header and does not require HTTP cookies, session identifiers, or login pages.

An HTTP user agent, such as a web browser, uses an Authorization header to provide a user name and password in each HTTP request. The header is specified as Authorization: Basic <credentials>, where credentials are the Base64 encoding of the user ID and password joined by a colon, as shown in the following example.

Sources:

Quarkus provides form based authentication that works in a similar manner to traditional Servlet form based auth. Unlike traditional form authentication, the authenticated user is not stored in an HTTP session, as Quarkus does not provide clustered HTTP session support.

Instead, the authentication information is stored in an encrypted cookie, which can be read by all members of the cluster (provided they all share the same encryption key).

Sources:

The Web Authentication API (also known as WebAuthn) is a specification written by the W3C and FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. The API allows servers to register and authenticate users using public key cryptography instead of a password.

With WebAuthn, servers can integrate with authenticators such as the YubiKey, a USB token, a smart phone, Apple’s Touch ID, and Windows Hello. The private key is securely stored on the device, while the server stores the public key and randomly generates challenges for the authenticator to sign. The signature proves possession of the private key, and the random challenge prevents replay attacks. source

Sources:

Quarkus provides mTLS authentication so that you can authenticate users based on their X.509 certificates.

Mutual TLS Authentication Concept

Supporting secure connections with SSL

The Bearer Token mechanism extracts the token from the HTTP Authorization header. The Authorization Code Flow mechanism redirects the user to an OIDC provider to authenticate the identity of the user. After the user is redirected back to Quarkus, the mechanism completes the authentication process by exchanging the provided code that was granted for the ID, access, and refresh tokens.

Als OIDC-Provider werden oft Google, Microsoft, Yahoo, …​ verwendet.

Als on-premise Lösung verwenden wir Keycloak

Begriffe

Sources

Man muss nicht Keycloak verwenden, sondern kann anstelle dessen die JWT selbst erzeugen und verwenden.

The quarkus-smallrye-jwt extension provides a MicroProfile JSON Web Token (JWT) 1.2.1 implementation and multiple options to verify signed and encrypted JWT tokens and represents them as org.eclipse.microprofile.jwt.JsonWebToken.

quarkus-smallrye-jwt is an alternative to the quarkus-oidc Bearer Token authentication mechanism, and verifies only JWT tokens by using either PEM keys or the refreshable JWK key set. quarkus-smallrye-jwt also provides the JWT generation API, which you can use to easily create signed, inner-signed, and encrypted JWT tokens.

Begriffe:

Sources

Alternative (Vorläufer) von oidc

sources:

durch Annotationen in den Endpoints wird der Zugriff durch Rollen geregelt.

Identity-Provider

Der Provider (zB Keycloak) enthält alle Infos welche Reolle auf welche Endpoints zugreifen darf.