Role of the Identity-Backend
Security architecture by showing how identity-backend interacts with other services (like logging-backend, notification-backend) and manages secrets.
Key Components
-
Identity-Backend
-
Central authority for issuing and verifying JWTs.
-
All other microservices (logging, notifications, etc.) depend on it for authentication.
-
Prevents each service from managing its own keys, reducing complexity.
-
-
Other Microservices (e.g., Logging-Backend, Notification-Backend)
-
Consume JWTs issued by identity-backend.
-
Validate tokens against known
JWT_ISSUERand shared key (JWT_SECRET_KEY) stored in their environment.
-
-
Environment Variables
-
Each service (including identity-backend) uses environment variables:
-
JWT_SECRET_KEY: Shared HMAC secret used for signing and verifying tokens (MVP). -
JWT_ISSUER: Must always equal"identity-backend"to confirm the token’s origin.
-
-
Flow
-
Token Issuance:
Client (or service) requests token from identity-backend → identity-backend signs it withJWT_SECRET_KEY. -
Token Usage:
Client/service includes token inAuthorization: Bearer <token>when calling another microservice (e.g., logging). -
Validation:
Receiving service (logging-backend) verifies:-
Signature using
JWT_SECRET_KEY. -
Issuer claim matches
identity-backend. -
Audience claim matches intended service.
-
Expiry is valid.
-
Why This Design Works
-
Centralized Trust: One place to manage signing keys.
-
Scalable: Add new microservices without changing token generation logic.
-
Config Simplicity: Only two env variables per service for MVP.
-
Future-Proof: Can evolve to asymmetric keys (public/private) later.
Comments
Post a Comment