OAuth access tokens: serialize single-valued aud as a string; make multi-audience a policy-gated opt-in

[saucam]

Problem

aud is modeled as a Go slice (domain/token.go:14 — Audience []string) and is always set from a []string (internal/service/credential.go:382). lestrrat-go/jwx serializes a slice as a JSON array regardless of length, so even a single-audience access token emits the array form:

"aud": ["https://rs.example.com"]

rather than the bare string "aud": "https://rs.example.com".

RFC 7519 §4.1.3 permits aud to be either a single case-sensitive string or an array. For the OAuth access-token profile a single string is the safer default: a multi-valued aud is a bearer pattern that enables lateral movement — a token valid for both RS-A and RS-B can be replayed from one to the other by whoever holds it. Sender-constraining via DPoP (RFC 9449) mitigates replay, but a sender-constrained token and a multi-audience token do not compose cleanly, so single-audience is the right default for the AT profile.

Proposed change

1. For the OAuth access-token profile, serialize aud as a single string when there is exactly one value.
2. Keep array semantics where SPIFFE JWT-SVID consumers expect them (JWT-SVID requires a non-empty array).
3. Treat multi-audience as an explicit, policy-gated opt-in rather than the default path.
4. No verify-side change needed — jwx handles the polymorphic (string-or-array) aud transparently on parse.

Relationship to other issues

• Depends on OAuth access tokens: aud defaults to the issuer — adopt RFC 8707 resource indicators so it names the target resource server #199 (RFC 8707 resource indicators). Once a caller can name the target resource, a single requested resource produces a single-string aud naturally; this issue is best sequenced after OAuth access tokens: aud defaults to the issuer — adopt RFC 8707 resource indicators so it names the target resource server #199.
• Sibling to OAuth access tokens: use RFC 9068 at+jwt typ header (config-overridable) #189 (the at+jwt profile move). Same access-token profile, complementary change — OAuth access tokens: use RFC 9068 at+jwt typ header (config-overridable) #189 covers the typ header only, this covers aud serialization.

References

• RFC 7519 §4.1.3 — aud is a single string OR an array
• RFC 8725 (JWT BCP) / RFC 9700 (OAuth 2.0 Security BCP) — audience-restriction guidance
• Reported by Andrii Deinega via WIMSE WG review of ZeroID.

[adeinega]

Thanks @saucam, one additional point I'd like to add is that struct IssuedCredential in https://github.com/highflame-ai/zeroid/blob/main/domain/credential.go doesn't have field Aud (as a string or as an array of strings) at this moment and I guess, you (do) want it to be stored in the database.