Identity-Backend Solution Design - Boundary and Identity Provider

All microservices (e.g., Microservice-1, Microservice-2, … Microservice-N) within a boundary trust tokens issued by the identity provider

Identity-Backend acts as the root of trust for authentication.


  • All JWTs are generated and signed by identity-backend, ensuring a unified security model.

  • When Microservice-1 calls Microservice-2, both rely on tokens from identity-backend; they do not issue their own tokens.

Simplified Key Management

  • Shared validation logic: only identity-backend holds signing keys (or secret); other services hold public keys (for asymmetric) or same HMAC key (for MVP).

Scalability and Rotation

  • If you rotate keys, only identity-backend changes; other services just refresh their validation keys.
Implications
Inside Boundary:
Services trust JWTs signed by identity-backend and validate claims (issuer, audience, expiry).

Outside Boundary:
Any request entering from the public internet must first be authenticated via identity-backend before interacting with internal services.

Consistency Requirement:
All microservices must agree on:

JWT_ISSUER value (identity-backend).

Which audiences (aud) are valid.

The secret or public key used for verification.





Comments

Popular posts from this blog

Feature: Audit log for one login, and identity service

Getting started - Build your data science lab environment

QA - Run #1 - Results