Keycloak is an OpenID Connect (OIDC) provider for a Quarkus application. It holds registered-user information and handles authentication, so an application can identify a logged-in user rather than treating every visitor as anonymous. section 6.1.2 section 3.4.1
Start with a development setup, then secure the application:
- Add the OIDC extension with `quarkus extension add oidc`. In Dev mode, Quarkus Dev Services starts Keycloak in a container; Docker or Podman must be available. section 3.4.1
- Require authentication for application paths and configure OIDC as a web application when securing browser-facing pages. Keycloak supplies the login screen. section 6.1.2
- Use the Dev UI to obtain a token, send it as an `Authorization: Bearer` header, and inspect the authenticated principal through `SecurityContext`. section 3.4.1
Listing 6.3 Security-related configuration in the Users service
quarkus.http.auth.permission.all-resources.paths=/* quarkus.http.auth.permission.all-resources.policy=authenticated quarkus.oidc.application-type=web_app quarkus.oidc.logout.path=/logout
This Users service configuration requires authentication on all paths, selects the OIDC web-application type, and sets a logout path. section 6.1.2
Multiple Quarkus applications can share one Dev Services Keycloak container, allowing services such as Users and Reservation to use the same provider. The first application owns that container: stopping it can disrupt the others. Dev Services does not supply a production Keycloak deployment. For production mode, run Keycloak yourself, configure its security realm, and give both applications the connection details. A PostgreSQL database provides a more robust alternative to Keycloak’s default, nonpersistent embedded H2 setup. section 6.1.2 section 6.4
