Primary ways you can configure your Spring Boot application to work with Keycloak
Scenario 1: Spring Boot as an OAuth2/OIDC Client (Web Application with User Login)
| Item | Description |
|---|---|
| Description | Your Spring Boot application acts as a client that needs to authenticate users. It redirects users to Keycloak for login. After successful authentication, Keycloak redirects back to your application with an authorization code, which is then exchanged for tokens (ID Token, Access Token). The application then typically manages the user's session. |
| Keycloak's Role | Authorization Server |
| Spring Boot's Role | OAuth2/OIDC Client |
| Use Case | Traditional web applications where users log in to access web pages and features. |
Loading...Loading...How it reflects in security: Authentication is delegated to Keycloak. Spring Security handles the OIDC flow, creates a SecurityContext with an OAuth2AuthenticationToken (containing an OidcUser), and manages the session.
Authorization can then use roles extracted from the token.
Scenario 2: Spring Boot as a Resource Server (Protecting APIs)
| Item | Description |
|---|---|
| Description | Your Spring Boot application exposes APIs that are consumed by other clients (e.g., a frontend SPA, a mobile app, other microservices). These clients obtain an access token from Keycloak and include it as a Bearer token in the Authorization header when calling your Spring Boot API. Your application validates this token. |
| Keycloak's Role | Authorization Server (issues tokens that this RS validates) |
| Spring Boot's Role | Resource Server |
| Use Case | Backend APIs, microservices |
| "Resource Server for authentication only" – Interpretation | If by this you mean your Spring app delegates the authentication process to Keycloak and then validates tokens issued by Keycloak to authenticate API requests, this is the scenario. The "authentication" here is the act of validating the presented token. |
Loading...Loading...How it reflects in security: Spring Security sets up a filter to intercept incoming requests, extract the Bearer token, validate its signature against Keycloak's public keys (fetched from JWKS URI), check issuer, expiration, and optionally audience.
If valid, it creates a SecurityContext with a JwtAuthenticationToken. No session is created by default for these requests; it's stateless.
Scenario 3: Spring Boot as Both OAuth2 Client and Resource Server
| Item | Description |
|---|---|
| Description | Your Spring Boot application has both a user-facing web part (requiring login via Keycloak, like Scenario 1) and exposes APIs that can be called with a Bearer token (like Scenario 2). |
| Keycloak's Role | Authorization Server |
| Spring Boot's Role | Both OAuth2 Client and Resource Server |
| Use Case | A monolithic application that serves a UI and also has an API for a mobile app or SPA frontend. |
Loading...Loading...How it reflects in security: Two distinct security mechanisms co-exist. /api/** paths expect Bearer tokens and are stateless. Other paths might use session-based security after an OIDC login.
Scenario 4: Spring Boot as a Client for Service-to-Service Communication (Client Credentials Grant)
| Item | Description |
|---|---|
| Description | Your Spring Boot application is a backend service that needs to call another Resource Server (which could be another Spring Boot app or any API secured by Keycloak). It authenticates itself to Keycloak using its own credentials (client ID and secret), not on behalf of a user. |
| Keycloak's Role | Authorization Server |
| Spring Boot's Role (this app) | Client using Client Credentials Grant |
| Spring Boot's Role (called app) | Resource Server (like Scenario 2) |
| Use Case | Microservice-to-microservice communication where no user context is involved in the direct call. |
Loading...Loading...How it reflects in security: This Spring Boot app acts as a client, programmatically fetching tokens from Keycloak using its own identity. The target Resource Server would validate this token (as in Scenario 2).