Designing an Identity Provider for a Developer Community

Fragmented authentication is one of the quietest sources of friction in a multi-app ecosystem. Every new app reinvents login, sessions, and roles — and each one does it slightly differently. 48ID exists to remove that tax.

The goal

One trust anchor that every app in the K48 ecosystem can rely on:

• Centralized identity and user records
• Standards-based token issuance (OAuth2 + OpenID Connect, JWT)
• Role-based access control (RBAC)
• Single sign-on across apps like 48Hub

Why API-first

Treating the identity provider as a product with a clean API — rather than a library bolted onto one app — means new student projects can integrate auth in less than a day instead of rebuilding it from scratch.

POST /oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=...&client_id=48hub

The stack

The service runs on Spring Boot 3 with Spring Modulith to keep boundaries clean, PostgreSQL for persistence, and Redis for sessions and short-lived tokens. The admin portal is a Next.js 16 BFF.

The hard part of identity isn't the crypto — it's the boundaries. Decide early what is a session, what is a token, and who is allowed to mint each one.

If you're building something similar, start with the token lifecycle on paper before you write a line of code. Everything else follows from it.