Multi-Token Authz (Revisited)

Multi-Token Authz (Revisited)

I want to revisit the The Multi-Token Authz Challenge, in light of recent revisions to the design of the Cedarling’s new multi-issuer token authorization interface — particularly its limitation of only allowing one token of each type per issuer.

The Internet is inherently federated — i.e. multi-domain. Each domain has one or more “issuers” — systems that mint JWTs. The current Cedarling authorization interfaces only allow one token per type (access_token, id_token, etc.) per authorization request. Although you could technically provide an access_token from one domain, and an id_token from another domain (if both issuers are trusted), in the current Cedarling authorization interfaces, you could not present an id_token from two different issuers.

Technical Challenge

The core technical challenge is enabling Cedar-based authorization policies to reason about multiple JWT tokens from different issuers without compromising security, performance, or policy complexity. Key technical constraints include:

1. Non-Deterministic Input Prevention: Multiple tokens of the same type from the same issuer create ambiguous authorization context
2. Dynamic Token Type Support: Custom token types (beyond standard OAuth tokens) must be supported without pre-defining schemas
3. Stable Token Naming: Token references in policies should avoid hard coding DNS domain names which may change
4. Policy Ergonomics: Authorization policies must remain readable and maintainable despite increased complexity

Solution Architecture

The Cedarling is introducing a new authorize_multi_issuer interface that processes an array of JWT tokens with explicit type mappings. The solution employs:

Individual Token Processing

• Each token is validated and processed separately (no token joining or merging)
• Dynamic Cedar entity creation based on specified mapping
• Predictable field naming using trusted issuer metadata: {issuer}_{token_type}

Security-First Design

• Strict validation prevents multiple tokens of the same type from the same issuer
• Secure field naming algorithm uses trusted issuer configuration to prevent confusion
• Failed token validation (e.g. expired token) doesn’t block processing of valid tokens

Schema Flexibility

• Operates without predefined schemas for rapid development
• Optional Cedar schema integration enables enhanced type safety in production
• All JWT claims stored as Sets of strings for consistent policy interface

What kind of new Challenges Could Multi-Issuer Policies Solve?

Here are just a few ideas:

1. Multi-Partner B2B Authorization: A trade association voting system needs to verify both membership tokens from the association and representative credentials from member companies.

2. Simultaneous validation of platform attestations, identity tokens, and verifiable credential: A mobile banking application requires (1) a Google Integrity API attestation to show the app has not been modified, and is running on a non rooted device, (2) an authenticator the FIDO Aliiance that the authenticator uses a non-exportable private key, and (3) that a verifiable credential has been presented by a trusted government issuer.

3. Consent: A payment processor requires a JWT assertion from a trusted consent service in addition to an identity token from a different home IDP that includes settlement details.

4. On Behalf Of (“OBO”) Authorization / Delegation: An AI service needs to validate both a new OBO OAuth token and a transaction token issued by a different domain API provider.

Cedar’s Formal Reasoning Advantages

Using Cedar to reason on tokens from multiple issuers enables enterprises to scale compliance using formal reasoning.

• Formal Cross-Token Validation: Cedar can formally verify that multi-issuer policies correctly implement business rules, such as ensuring trade association voting requires both valid membership AND representative credentials
• Provable Security Properties: Mathematical analysis can prove that the multi-issuer system prevents token confusion attacks and maintains issuer separation guarantees
• Scalable Policy Complexity: Cedar’s formal foundation enables sophisticated authorization logic across multiple token sources without performance degradation or logical inconsistencies
• Audit Trail Precision: Cedar’s deterministic evaluation provides exact reasoning traces for compliance auditing, showing precisely which tokens and claims influenced each authorization decision

Strategic Business Value

• Risk Reduction: Formal verification eliminates entire classes of authorization bugs that could lead to security breaches or compliance violations in federated environments
• Regulatory Confidence: Mathematical proofs of policy correctness provide auditable evidence for regulatory compliance in industries requiring multi-authority validation
• Partnership Velocity: Cedar’s ergonomic syntax accelerates B2B integration by making complex multi-issuer authorization rules understandable to business stakeholders
• Operational Excellence: Microsecond authorization decisions enable real-time federated applications without performance trade-offs

Conclusion

The multi-issuer authorization capability leverages Cedar’s formal reasoning foundation to solve complex federated identity challenges with mathematical precision. By extending Cedar’s formal verification capabilities to multi-token scenarios, this enhancement delivers:

• Provable Correctness: Mathematical guarantees that multi-issuer policies behave exactly as intended
• Performance at Scale: Microsecond authorization decisions across complex token combinations
• Audit-Ready Transparency: Formal reasoning traces that satisfy regulatory compliance requirements
• Business-Readable Policies: Ergonomic syntax that bridges technical implementation and business requirements

This solution transforms federated authorization from a complex integration challenge into a formally verified, high-performance capability that enables new business models while maintaining Cedar’s core advantages of speed, clarity, and mathematical certainty.

After around 100 iterations of the design document, we’re finally moving forward with implementation in the Cedarling at the Linux Foundation Janssen Project. To follow the progress, see issue Jans-11834.