CareerGPT

Next steps

Resources

Architecture - Excalidraw

High level design


Identity-Backend

Deploy an MVP identity service that securely authenticates, and authorizes both users and services; lay the foundation for fine-grained permissions, SSO, and a Zero Trust Model.

Architecture
  1. Microservice IAM
    1. JWT issuer is centralized, consumers delegate all authentication and authorization decisions to identity-backend
  2. Federated trust
    1. JWT issuer is centralized, consumers validate locally (no DB calls)
  3. Claim-based authorization 
    1. Roles/scopes embedded in JWT, no API calls for every check
  4. Finite State Machine
    1. Users progress via well defined transitions (guest -> subscriber)
Core principles
  • Single source of truth - Identity service is the only place that knows secrets, roles, and policies. All services trust it’s JWTs
  • Modular design - Start with service to service, plug in SSO, RBAC, and etc later without breaking things
  • Token-centric security - JWTs as the unit of trust, easily extensible (Claims, scopes, expiration policies)
  • Database backed configuration - mvp can use sqllite but schema supports migration to MySQL/PostgreSQL with redesign
  • Zero-trust ready - build in mutual validation (issuer, audience, key rotation) even if not enforced day one.

Service-to-Service Solution Design

MVP-Design-Iteration-1 - Using one shared secret across all services creates a single point of failure and blocks secure, scalable authentication.

Problem Summary

Core Issue:
We currently use a single static secret for JWT signing and validation across all microservices, meaning if one secret is leaked or rotated, every service is affected. This prevents per-service isolation, token revocation, and proper scaling.

How We Arrived at the +1 Design

  1. Recognized Security Gap:
    Static secret = no isolation, no rotation, no per-client control.

  2. Decoupled Trust via Identity Service:
    Identity-backend becomes the trust anchor issuing JWTs, while logging-backend (and others) only validate tokens.

  3. Planned Multi-Secret Architecture (+1 Design):

  • Store key_id → secret_value pairs.

  • Each client/server pair gets its own key_id.

  • JWTs include kid (key ID), so validation uses the right secret.

  • Identity-backend manages all keys centrally (in SQLite for MVP, scalable later).

  1. Scalable Benefits:

MVP-Service-Secrets-Issue-1 - Current JWT setup uses one shared secret across all services, making rotation, revocation, and client isolation impossible as we scale. 

Problem Statement (Summary)

Our current microservice authentication uses a single shared secret (JWT_SECRET_KEY) across identity-backend (issuer) and logging-backend (consumer). While simple, this approach causes major issues as we scale:

  • Single point of failure – If the secret is leaked or rotated, all services break.

  • No client isolation – All clients use the same secret, making it impossible to audit or revoke a single client.

  • No key rotation strategy – Rotating secrets requires redeploying all services simultaneously.

  • Limited flexibility – Cannot issue different secrets per client-service pair.

We need a multi-key, per-client secret management system using kid (key ID) in JWT headers, allowing:

Why Use Multiple Shared Secrets

  1. Compartmentalization

    • If one service’s secret leaks, only that service’s communications are compromised.

    • Other services remain secure without needing global rotation.

  2. Per-Service Access Control

    • You can revoke a single client/service’s secret without affecting the others.

  3. Audit and Debugging

    • Easier to trace requests to a specific client (by sub claim) and validate using that client’s secret.

  4. Future Scalability

Read more

CareerGPT-Backend

API Gateway, enforces policy

Validates JWTs before routing to microservices

Applies rate limiting, logging, anomaly detection


Comments

Post a Comment

Popular posts from this blog

Feature: Audit log for one login, and identity service

Image
Customer (Product) Page High-Level System Design Diagram (PlantUML) Sequence Diagram: Audit Event Ingestion Sequence Diagram: Orchestration Event For a High-Level System (Component) Diagram The queue is implemented as message_queue (generic), and the audit log service consumes from it, writing to a dedicated audit_log table. The logging service also consumes from the same message_queue and writes to log_store. Orchestration/other services use the same queue. Summary Table: What Writes Where Event Type Goes Into Consumed By Final Storage audit message_queue Audit Log Service audit_log table log message_queue Logging Service log_store table doc_uploaded message_queue Orchestration Worker (business DB, or triggers next event) ocr_ready message_queue Notification Worker, etc. (notification log, etc.)  Core Tables message_queue – universal event bus (temp buffer) audit_log – immutable audit/compliance events log_store – application logs (op...
Read more

Getting started - Build your data science lab environment

This guide explains how to set up a complete data science environment for the udemy program. A proper setup ensures compatibility and avoids recurring environment issues.  1. Overview Goal : Create a full-featured environment with sufficient resources for all course exercises. Recommendation : Use Anaconda for the most reliable setup. Alternative : Use a Python virtual environment with pip if Anaconda isn’t working. 2. Setup Options Primary (Recommended) Create a dedicated Anaconda environment (isolated, compatible). Alternative Use a standard Python virtualenv + pip (faster but less reliable). 3. Windows Setup Steps Clone Course Repository git clone https://github.com/ed-donner/llm_engineering/ Follow the repository’s README.md instructions for additional setup details. Create Anaconda Environment Inside the llm_engineering folder: conda env create -f environment.yml ⏳ This may take several minutes. Activate the environment: conda activate llms Deactivat...
Read more

QA - Run #1 - Results

Image
# QA Report for Tag QA_July2025_A - **Tag/Commit:** QA_July2025_A (`f32abc1`) - **Date:** 2025-08-01 - **QA Outcomes:** All tests passed except for file upload (see below)... - **Environment:** Windows 10, Python 3.12, requirements.txt as of tag - **Notes:** See log for detailed results. ## Issue Found - **Step:** - **Bug:** - **Log excerpt:** - **Screenshot:** For this QA run, we begin with pristine state by: Stop all services Delete logs.db, and jobs.db Delete all files in doc_store folder Start all services Test, you should see no data on index page, and query should result in no data found error Next, go ahead and upload new1.txt, and after that new2.txt Issue the query: "can you summarize all of the todo items you can find, seperating each one on a single line, with due date first, then title, and description with any details you can augment" Expected Answer: - August 1, 2025: Respond to Amira and discuss weekend plans - August 3, 2025: Go to Somesh class and finish ta...
Read more