JWT - Subject and Audience

sub identifies who is calling (CareerGPT), while aud identifies which service the token is for (Logging), ensuring scoped, secure service-to-service communication.

The sub and aud fields are part of JWT claims and reflect standard identity and authorization semantics in distributed systems:

  • Subject (sub) → Represents the caller’s identity (e.g., CareerGPT microservice).

  • Audience (aud) → Defines the intended recipient/service (e.g., Logging microservice).

  • This pattern is known as service-to-service authentication (or machine-to-machine auth) and supports principle of least privilege by scoping tokens to a specific target.

  • Architecturally, this is part of a Zero Trust microservices architecture, where issuer (iss) is the trust anchor and tokens are validated per service boundary.

For example consider the following endpoint, and request body

Endpoint: 

POST /token 

Request Body Example:

{

 "sub": "careergpt-backend", 

 "aud": "logging-service


1. What is sub (Subject)?

  • Represents who the token is about — the entity (service, user, or client) that is being authenticated.

  • In your example:

    "sub": "careergpt-backend"
    

    This means the token is being issued to the CareerGPT backend microservice.

  • Purpose:

    • Lets downstream services (e.g., Logging-Backend) know which service is making the request.

    • Supports auditing (e.g., “Which service generated this log entry?”).

    • Enables revocation or scoping of tokens per service if needed later.


2. What is aud (Audience)?

  • Represents who the token is intended for — the target service that will validate and accept the token.

  • In your example:

    "aud": "logging-service"
    

    This means the token is meant to be presented to the Logging-Backend service.

  • Purpose:

    • Ensures that even if the token is stolen, it can only be used with the intended service (audience check).

    • Prevents token reuse across unrelated services (e.g., a Logging token can’t be used against Notification-Backend).


Why this combination is important

  • sub = careergpt-backend: Identifies the caller.

  • aud = logging-service: Identifies the recipient.

  • Together, they create a trust contract:

    • CareerGPT requests a token to talk to Logging.

    • Identity-Backend signs a token that explicitly states: “This token is for Logging, and it was issued to CareerGPT.”

    • Logging-Backend validates:

      • Issuer = Identity-Backend

      • Audience = Logging-Backend

      • Subject = CareerGPT-Backend (for auditing/logging)


Benefit in your architecture


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