The role of the identity-backend

 Great question.

The short answer is:
No, the identity-backend does NOT authorize each request directly.

Let me explain, principal engineer style:

1. What Does identity-backend Do?

  • It authenticates users (verifies their username/password) and issues JWT tokens.

  • It also provides endpoints to:

    • Issue tokens (/token)

    • (Optionally) verify tokens (/verify endpoint, if you call it)

    • Return OIDC metadata for clients

But:
After issuing the JWT, it is NOT in the request path for every user or API call.

2. Who Actually Authorizes?

  • The other services (API Gateway, Worker, Logging, etc.) are responsible for authorization.

  • How?

    • They check the JWT token provided by the client (from session, cookie, or Authorization header).

    • They verify its signature, issuer, audience, and expiry.

    • If the token is valid and unexpired, the request is authorized to proceed.

This is called a "stateless" architecture:

  • The services trust the signed JWT (which can’t be faked if secret is safe).

  • There is no need to call identity-backend for every request—this is why JWTs scale.

3. What About Fine-Grained Authorization?

  • Who does what (e.g., roles, access levels) is usually encoded in JWT claims (scope, roles, etc.).

  • The receiving service (API Gateway, etc.) decides, based on those claims, if the request is allowed.

  • The identity-backend is not consulted in real-time.

4. Is This Good?

Yes, for almost all modern architectures!

  • It offloads the authentication bottleneck.

  • Reduces latency (no round-trip to auth server for every request).

  • Each service must verify JWTs securely (with correct secret or key).

5. What If I Want Central Real-Time Authorization?

  • You’d need an API gateway or middleware that calls the identity service on every request (not common unless you need instant token revocation or auditing).

  • Even then, best practice is: Self-contained JWTs, validated by each service.

  • If you must, you can implement token blacklists or short TTLs, but you’ll rarely want to make identity-backend a bottleneck.

Summary Table

Service Authenticates Users? Issues JWT? Authorizes Each Request? Verifies JWT?
identity-backend Yes Yes No (optional)
API Gateway No No Yes Yes
Worker, Logging No No Yes (if needed) Yes

Bottom Line

  • identity-backend is the authenticator and token issuer—not a request firewall.

  • Your services are the authorizers—they verify tokens for each request.

If you want to see where the authorization happens, look for code that checks or verifies JWTs in your API Gateway and other services—not in identity-backend itself.

Let me know if you want a code walkthrough of how the token check happens in your API Gateway, or how to make it even more robust!

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