For modern applications, authentication is usually divided into two types: External User Authentication (human users accessing the system) and Service-to-Service Authentication (microservices communicating securely with each other).
External Users — Using Keycloak
Human users via frontend / SPA / app
Keycloak acts as the central Identity Provider (IdP) for external users. This means all user logins, registrations, social login integrations, password resets, and multi-factor flows are handled via Keycloak. When a user signs in (for example, renting a car through your site), the application redirects to the Keycloak login page. Upon successful authentication, Keycloak issues a JWT (JSON Web Token) that is returned to the application. This JWT can then be included in API requests for authorization and user identification in all downstream microservices.
Example Workflow:
The user goes to your app and clicks "Login".
User is redirected to Keycloak and completes authentication (username/password, OTP, or social provider).
Keycloak issues a JWT, which the SPA/web app or mobile app stores securely.
The JWT is sent in the Authorization: Bearer header to your APIs, which validate the JWT using Keycloak’s public key before allowing access.
Service-to-Service Authentication
Backend service/microservice to another service
Service-to-service authentication is about securing API calls between your backend microservices (e.g., booking, payment, user profile). The main focus here is making sure each microservice call is trusted and, if needed, traced back to an authorized source.
For now, you may use an API key, static tokens, or internal mutual TLS (mTLS) for these calls if your services are within a secured/VPC network. JWTs issued by Keycloak may also be used for service-to-service calls, where each service validates incoming tokens the same as external calls.
Example Workflow (API Key approach):
Microservice A calls Microservice B, attaching an API key in the request headers (e.g., x-api-key: SECRET).
Microservice B verifies the API key against a secure store before processing the request.
Example Workflow (JWT tokens):
Microservice A attaches the JWT received for the user (from the external authentication) or a dedicated service JWT.
Microservice B verifies the JWT signature with Keycloak’s public key, checks the token’s claims, and processes the request.
External users authenticate via Keycloak to get secure, standardized tokens for app and API access.
Service-to-service calls can use simpler API keys, mTLS, or even reuse JWTs from Keycloak, but Keycloak is essential for external user flows and auditability.
Common Approaches
API Keys:
Each service presents a unique API key in request headers (e.g., x-api-key: SECRET). The receiving service validates this key from a secure list.
Example: Service A includes x-api-key in requests to Service B, and Service B verifies it before processing.
Mutual TLS (mTLS):
Both microservices exchange and validate certificates during connection. It ensures that only services with valid, signed certificates can communicate.
Example: Service A and B each have X.509 certificates. Both sides authenticate one another on every connection.
OAuth 2.0 Client Credentials Grant:
Each service registers with an authorization server (like Keycloak) and authenticates using a client ID and secret to receive a short-lived access token (JWT).
Example: Service A requests a token from Keycloak, then presents it to Service B, which verifies the token and grants access.
JWT Tokens:
Services exchange stateless, signed JSON Web Tokens. Each service validates the signature and claims in the JWT before granting access.
Example: Service A attaches a JWT as a Bearer token; Service B validates it using a shared secret or public key.
Service Mesh Solutions (e.g., Istio, Linkerd):
Mesh injects sidecar proxies into each service, automatically securing connections (often with mTLS) and enforcing policy without app-level code changes.
Example: Traffic between Service A and B is transparently encrypted and authenticated by the service mesh, with centralized security policies.
Example Scenarios
Billing and invoice service fetching customer data from a profile service with mTLS or JWT tokens.
Notification service using OAuth 2.0 Client Credentials flow to push alerts to a messaging service.
Microservices within a Kubernetes cluster using Istio mesh for automated mTLS protection and identity management.
Top comments (0)