A single audience value gets converted into a set with one entry about jjwt HOT 1 CLOSED

Just for some background context for the current (0.12.0+) behavior:

The single-string audience claim was implemented in JJWT before JWT RFC 7519 was finalized, and the RFC draft spec used at the time when implementing JJWT said aud was a single StringOrURI value, e.g. see RFC 7519, draft 5, section 4.1.5

The RFC spec committee later changed the aud data type to be, in the general/normal/standard case a JSON array of StringOrURI values, but then they said it may also be a single StringOrURI (non-array) value, presumably to ensure existing usages could still be supported. See the now-finalized RFC 7519, Section 4.1.3.

This poses a frustrating challenge for Java libraries that are strongly-typed, where people don't like their data types changing randomly.

So, starting in 0.12.0, we added the .audience() builder to help support this odd 'type-changing' use case, and the parser will always 'normalize' a single value into a Set<String> so the app developer doesn't have to perform weird type conversion logic/checks in their application code.

Based on the reported behavior, the problem at the moment is that the .claims(claims) method - which is called after using an .audience() builder - treats the object as a Map<String,?>, and just uses standard claim-to-value logic for each Map entry, and the standard behavior is to treat aud as a JSON array per the finalized RFC.

In other words, the 'last call wins' as to the behavior seen.

Based on this it seems as if generic claim, put, putAll logic should explicitly check for the aud special case, and if a single string, delegate the .audience().single(String) method instead of the simple map direct 'put'.

As you've indicated, there is a workaround for this for applications - just call the .audience() builder after general claims are set, but I do understand how that's less desirable than it 'just working' regardless of method call order.

We'll use this ticket to track the work to implement this special case logic. Thank you for opening it!

from jjwt.