Service-to-Service Authentication Patterns

Token Relay (Propagate User Token)

Concept: Pass the original user's access token through the entire call chain.

Use Case: When downstream services need to know WHO the end-user is and make authorization decisions based on that

✅ PROS:

• Maintains user context across all services

• Simple to implement

• Each service can check user permissions

• Audit trail shows real user

• No additional tokens needed

❌ CONS:

• User token might expire mid-request chain

• All services must validate same token (overhead)

• Tight coupling to user token format

• No differentiation between user and service calls

• Token might have unnecessary scopes for internal calls

🎯 BEST FOR:

• Simple architectures

• When you need user context everywhere

• Synchronous request chains

Service Account Token (Client Credentials)

Use Case: When service needs to act on its own behalf, not on behalf of a user.

Pros:

✅ Service acts with its own identity ✅ Narrowly scoped permissions ✅ Longer-lived tokens (can cache) ✅ Better security isolation Cons:

❌ Loses original user context (must pass separately) ❌ Need to manage service credentials ❌ Two tokens to validate

Mutual TLS (mTLS)

Use Case: High-security internal communication without token overhead.

Pros:

✅ No token management overhead ✅ Network-level authentication ✅ High performance (TLS termination) ✅ Works well with service mesh Cons:

❌ Complex certificate management ❌ Certificate rotation challenges ❌ No user context (must pass separately) ❌ All-or-nothing (service either trusted or not)

Detailed Video Upload Flow with Async Components