Authentication verifies who is using an application. A web page that initially identifies its visitor as anonymous can instead display a username after the visitor signs in. This matters when an HTML frontend and its backend services need to be secured together. section 6.0 section 6.1.2
In a Quarkus application, Keycloak can act as the OpenID Connect (OIDC) provider for registered users, while Quarkus delegates authentication to it. Dev Services can start Keycloak during development, avoiding the need to set up a realm and users manually for this example. section 6.1.2
Require authentication for the Users service
Set `quarkus.http.auth.permission.all-resources.paths=/*` and `quarkus.http.auth.permission.all-resources.policy=authenticated`. Configure `quarkus.oidc.application-type=web_app` and `quarkus.oidc.logout.path=/logout`. The resulting flow includes a Keycloak login screen; the WhoAmI page can then greet a signed-in user rather than display anonymous. section 6.1.2
The Users and Reservation services can share one Dev Services Keycloak container when both run in development mode. The first application manages that container: stopping it may disrupt the other application. Dev Services is not a production setup; production requires managing more of the Keycloak configuration yourself. section 6.1.2
