Skip to content
Hen Heang
Back to Projects
AuthHub — Reusable Authentication Service

Backend API · Personal Project

AuthHub — Reusable Authentication Service

Solo Developer — Backend 2026 — Present 1 developer
Source available
GitHub
  • Spring Boot 3
  • Java 17
  • PostgreSQL
  • Spring Security
  • JPA
  • Flyway

Project Summary

Problem

Every side project rebuilds the same login system — and rebuilds its bugs: tokens that can't be revoked, no MFA, password resets bolted on later. AuthHub extracts authentication into one service done properly once, with a sample to-do API demonstrating how any business service plugs into it.

Approach

AuthHub separates authentication from business features through a Gradle multi-module design. A sample todo API consumes the security module, proving the auth service works beyond an isolated demo.

What I Built

  • JWT access and refresh flows with database-backed revocation
  • TOTP MFA with hashed one-time recovery codes
  • RBAC administration, account recovery, and rate limiting
  • Audit logging plus a sample todo API secured by the auth module

Implementation

Spring Boot 3.5 and Java 17 in a Gradle multi-module build. PostgreSQL and Flyway own persistent auth state; Spring Security, JPA, MapStruct, CI checks, and a real Postgres test service support the implementation.

architecture

common-api shared library
security-api — JWT · MFA · audit (8080)
todoapi sample consumer (8082)
PostgreSQL + Flyway migrations
GitHub Actions CI (postgres:16)
Dependencies flow one way — common-api → security-api → todoapi — so the auth service can never depend on a business API. The schema belongs to Flyway: Hibernate only validates it, which turns silent schema drift into a startup failure. Auth state that must be revocable (refresh tokens, blacklisted JWTs, reset/verification/unlock tokens) lives in dedicated tables rather than in stateless token claims.

Backend Evidence

Core data

usersrolespermissionsuser_rolesrole_permissionsdevicesrefresh_tokensrevoked_tokens

Key endpoints

  • POST/api/auth/login

    Authenticate with credentials; issues JWT access + refresh tokens

  • POST/api/auth/oauth2/google

    Log in by verifying a Google ID token server-side

  • POST/api/auth/mfa/verify

    Complete login with a TOTP code or a one-time backup code

  • GET/api/admin/audit-logs

    Query the audit trail of security events (admin)

Engineering Decisions

  1. Challenge

    Supporting revocation and account recovery around stateless JWTs

    Decision

    Stored refresh, revoked, reset, and verification tokens in PostgreSQL

  2. Challenge

    Adding MFA without weakening the existing password login flow

    Decision

    Made MFA an explicit second step with hashed single-use recovery codes

Takeaways

  • Authentication is a product, not a feature — extracting it once beats re-implementing it in every project
  • Real security work is mostly edge cases: lockout, resend limits, token expiry, and recovery paths
Next Project

Hengo — AI Companion for Daily Growth