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:
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
-
This enables fine-grained security between services:
-
Each token is scoped to a single service-to-service call.
-
If you later add Notification-Backend, you can issue tokens specifically for it (
aud = notification-service) without changing others.
-
-
Makes it future-proof for multi-service scaling or third-party integrations.
Comments
Post a Comment