Introducing explicit JWT audiences for the strengthening security and enable scaliability

[john-cremit]

Summary

This proposal suggests adding explicit aud (audience) claims to the JWT tokens issued by the Nebula Authorization server. By doing so, each token can be targeted to a specific audience (e.g., an Authority server, a Backbone server), mitigating the risk of token hijacking and enabling secure scaling in multi-authority environments.

Motivation and goals

Motivation

Currently, Nebula's Authorization server issues tokens without an explicit audience, creating a few key vulnerabilities and limitations:

1. Token Reuse and Hijacking:
   Without an audience restriction, a compromised token could potentially be reused by a malicious authority against another authority or the Backbone server. This opens up avenues for unauthorized access and privilege escalation.

2. Scalability and Clarity in Multi-Authority Environments:
   As organizations add more Authorization servers and authorities, the lack of explicit audiences makes it hard to maintain clear boundaries. This ambiguity hinders system expansion and reduces the overall security posture in multi-authority setups.

Goals

• Ensure each token's intended recipient (e.g., a specific Authority, the Backbone server) is explicitly stated, preventing misuse across different components.
• Support a scalable, multi-authority architecture by enforcing explicit audience claims, ensuring cleaner and more secure token usage patterns.

In scope

• Introducing aud claims into JWT tokens issued by the Authorization server.
• Defining and registering known audiences (Authority servers, Backbone server) and corresponding identifiers.
• Adjusting the client (CLI) to request tokens for specified audiences.
• Ensuring that each Authority and the Backbone server strictly validates the aud claim in incoming tokens.

Out of scope

• Introducing alternative token formats beyond JWT.
• Building an entirely new infrastructure for audience discovery (although suggestions for discoverability are included).

Risks / unknowns

• Increased Complexity for Clients:
  Clients must now obtain separate tokens for each required audience. This creates operational overhead and assumes clients know their target audiences in advance.

• Dynamic Audience Management Challenges:
  If audience configurations change frequently, clients must update their logic and re-request tokens, which can complicate maintenance.

• Security Considerations:
  While aud claims enhance security, they must be rigorously verified. Token lifetimes, caching policies, and renewal strategies need to be well-defined to avoid introducing new attack vectors.

Examples

Example 1: Single Authority Token Request

• The client requests a JWT from the Authorization server for aud = ["authorityA"].
• The Authorization server issues a token including {"aud": ["authorityA"], ...}.
• When presented to Authority A, the token is validated against the declared audience before granting access.

Example 2: Backbone and Authority B Token Requests

• The client needs to interact with both the Backbone server and Authority B.
• The client requests two tokens: one for aud = ["backbone"] and another for aud = ["authorityB"].
• service receives a token intended solely for it, minimizing cross-service token reuse risks.

Potential Improvements and Alternatives

• Token Exchange Mechanism:
  Consider OAuth 2.0/OIDC Token Exchange flows. A client could start with a generic token and then exchange it for audience-specific tokens on demand. This approach minimizes upfront complexity and allows on-the-fly adaptation to changing audience requirements.