A standalone authentication service in Spring Boot, built to be dropped into other projects instead of rewriting login, registration and token handling every time.
It exposes a REST API for user registration and authentication, issues JWTs, and protects routes with Spring Security. It was extracted from a production web platform and reused as an independent service.
- Java 21, Spring Boot 3.5
- Spring Security for authentication and route protection
- JJWT 0.12 for token issuance and validation
- Spring Data JPA with PostgreSQL in production and H2 for local runs
- Bean Validation on request payloads
- Spring Boot Actuator for health and readiness endpoints
- Docker, with a deployment manifest for Render
Separate service, not a module. Authentication lives in its own deployable unit so that any application can point at it without inheriting the rest of a codebase.
Stateless authentication. The service issues a signed JWT on login; downstream services validate the token rather than calling back, which keeps the service off the request path of every protected route.
Two database profiles. H2 in memory for local development and tests, PostgreSQL in production, so the service can be started with no external dependencies.
Configuration through environment variables. Signing key, database credentials and token lifetime are read from the environment via dotenv-java; nothing sensitive is committed.
Requires JDK 21.
./mvnw spring-boot:runThe service starts with the H2 in-memory profile. Create a .env from the example below before running against PostgreSQL:
DB_URL=jdbc:postgresql://localhost:5432/auth
DB_USER=postgres
DB_PASSWORD=change-me
JWT_SECRET=a-long-random-value
JWT_EXPIRATION_MS=3600000
With Docker:
docker build -t login-microservice .
docker run -p 8080:8080 --env-file .env login-microservice| Method | Path | Description |
|---|---|---|
| POST | /auth/register |
Creates a user and returns a token |
| POST | /auth/login |
Authenticates credentials and returns a token |
| GET | /actuator/health |
Liveness and readiness |
Protected routes expect Authorization: Bearer <token>.
Stated openly, since this is an authentication service and the gaps matter:
- No refresh tokens. Sessions end when the access token expires.
- No rate limiting on login. Brute-force protection has to be handled upstream for now.
- No automated test suite yet. The test dependencies are in place; coverage of the authentication flow is the next step.
- No password reset or email verification flow.
- Planned: refresh tokens with rotation, login attempt throttling, role-based authorisation, and integration tests around the token lifecycle.
No license declared yet — add one before reuse.