Overview
SGIVU implements OAuth2.1 with OpenID Connect (OIDC) for authentication and authorization. Thesgivu-auth service acts as the Authorization Server, issuing JWT tokens that are validated across all microservices.
The auth server uses Spring Authorization Server with full OIDC compliance, including support for the Authorization Code flow with PKCE (Proof Key for Code Exchange).
Authorization Server (sgivu-auth)
Key Features
- Standards Compliance: OAuth2.1 + OIDC certified
- Token Format: JWT signed with RSA (JKS keystore)
- Grant Types: Authorization Code, Refresh Token
- Client Authentication: CLIENT_SECRET_BASIC
- PKCE: Required for all clients (enhanced security)
- Session Storage: PostgreSQL (JDBC sessions)
OIDC Endpoints
| Endpoint | Purpose |
|---|---|
/.well-known/openid-configuration | OIDC discovery metadata |
/oauth2/authorize | Authorization endpoint (initiates login) |
/oauth2/token | Token endpoint (exchanges code for tokens) |
/oauth2/jwks | JSON Web Key Set (public keys for JWT verification) |
/oauth2/introspect | Token introspection |
/oauth2/revoke | Token revocation |
/login | Login page (form-based authentication) |
Registered Clients
The auth server registers OAuth2 clients on startup viaClientRegistrationRunner:
1. sgivu-gateway (Production Client)
- Access Token TTL: 30 minutes
- Refresh Token TTL: 30 days
- Refresh Token Reuse: Disabled (rotation enabled)
2. postman-client & oauth2-debugger-client
Development/testing clients with similar configuration for Postman and OAuth2 Debugger tools.Authorization Code Flow with PKCE
SGIVU uses the Authorization Code flow with PKCE for all OAuth2 clients:PKCE Protection
PKCE (RFC 7636) protects against authorization code interception attacks:- Code Verifier: Random 43-128 character string generated by client
- Code Challenge: SHA-256 hash of code_verifier
- Flow: Challenge sent with
/authorize, verifier sent with/token - Verification: Auth server validates
SHA256(code_verifier) == code_challenge
OAuth2AuthorizationRequestCustomizers.withPkce():
JWT Token Structure
Access Token Claims
The auth server issues JWTs with custom claims viaOAuth2TokenCustomizer:
sub: User ID (not username!)username: Login usernamerolesAndPermissions: Combined roles (prefixed withROLE_) and permissionsisAdmin: Boolean flag for admin role detection
ID Token Claims
The OIDC ID token includes:The ID token has a 30-day TTL (same as refresh token) because it’s used as
id_token_hint during OIDC RP-Initiated Logout. Spring Security never refreshes the ID token, so it must remain valid for the session lifetime.Token Signing and Validation
Keystore Configuration
The auth server signs JWTs with an RSA key pair stored in a JKS keystore:- Keystore must NOT be committed to Git (
.gitignoreentry required) - Load from secret manager in production (AWS Secrets Manager, HashiCorp Vault)
- Rotate keys periodically using the
kid(key ID) claim
Public Key Discovery
Microservices validate JWTs by fetching the public key from the JWKS endpoint:- Fetches
/.well-known/openid-configuration - Retrieves JWKS from
/oauth2/jwks - Validates JWT signature using the public key
- Verifies
iss(issuer) andexp(expiration) claims
Scopes and Consent
Standard Scopes
openid: Required for OIDC (triggers ID token issuance)profile: User profile claimsemail: Email claimoffline_access: Enables refresh token issuanceapi: General API access
Authorization Consent
All clients require user consent (requireAuthorizationConsent: true):
- Users see a consent screen listing requested scopes
- Consent is stored in the
authorization_consentstable (PostgreSQL) - Subsequent logins skip consent if previously granted
Session Management
The auth server uses Spring Session JDBC to persist sessions:- Table:
SPRING_SESSION(PostgreSQL) - Cookie Name:
AUTH_SESSION - Cookie Settings:
HttpOnly=true,SameSite=Lax,Secure=false(usetruein production with HTTPS) - Max Sessions: 5 concurrent sessions per user
Token Revocation
The gateway revokes tokens during logout viaTokenRevocationServerLogoutHandler:
/oauth2/revoke before clearing the session.
Refresh Token Flow
The gateway automatically refreshes expired access tokens using the refresh token stored in the Redis session. See JWT Tokens for details.Production Considerations
Issuer URL
Set theISSUER_URL environment variable to match the public-facing URL:
- JWT
issclaim must match the issuer URL - OIDC discovery metadata includes this URL
- Mismatches cause token validation failures
HTTPS and Secure Cookies
In production:- Enable
Secureflag on cookies (setUseSecureCookie(true)) - Use HTTPS for all OAuth2 endpoints
- Configure CORS to allow only trusted origins
Client Secret Management
- Store client secrets in environment variables or secret managers
- Use strong, randomly generated secrets (not
gateway-client.secret) - Rotate secrets periodically
Related Documentation
- BFF Pattern - How the gateway manages tokens for Angular
- JWT Tokens - JWT structure and validation
- Service Communication - Internal service authentication