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

  1. 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.

  2. Other Microservices (e.g., Logging-Backend, Notification-Backend)

    • Consume JWTs issued by identity-backend.

    • Validate tokens against known JWT_ISSUER and shared key (JWT_SECRET_KEY) stored in their environment.

  3. 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

  1. Token Issuance:
    Client (or service) requests token from identity-backend → identity-backend signs it with JWT_SECRET_KEY.

  2. Token Usage:
    Client/service includes token in Authorization: Bearer <token> when calling another microservice (e.g., logging).

  3. 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

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