JWT Assertion payload does not match RFC example when generated with OIDC relying party about oidc

[hifabienne]

@muhlemmer @livio-a Is there a reason why we have an array in the aud?
Does that change with the new version of the OIDC lib?

[livio-a]

I've just checked section 4 and can't see a conflict in the implementation.
note the could:

Below is an example JSON object that could be encoded to produce the JWT Claims Set for a JWT:

Further the JWT RFC 7519 (https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) states that

[...] In the general case, the "aud" value is an array of case-
sensitive strings, each containing a StringOrURI value. In the
special case when the JWT has one audience, the "aud" value MAY be a
single case-sensitive string containing a StringOrURI value.

We certainly improve the serialization of a single string audience into a string, but i wouldn't classify it as a bug then.

[muhlemmer]

I second @livio-a his conclusion that our current implementation is valid. I just checked it without knowing he already replied.

causing errors when connecting to systems that require audience be a string value.

@Kunde21, can you be specific which systems are breaking on this? How would those systems handle multiple audience values? Would be strange if they work properly with multiple values (which they should) and break on a single value in an array.

Have you considered raising a bug or ticket at the "other" system?

We certainly improve the serialization of a single string audience into a string, but i wouldn't classify it as a bug then.

@livio-a we would end up again with more custom json marshalling on any claims bearing object, if we want to be consistent. Or use a separate type for all claims that allow the switch between string or array and have a marshal method on that. Either way it sounds like more code to maintain. I would abstain until it's proven to be absolutely necessary by the OP or others.

[livio-a]

We certainly improve the serialization of a single string audience into a string, but i wouldn't classify it as a bug then.

@livio-a we would end up again with more custom json marshalling on any claims bearing object, if we want to be consistent. Or use a separate type for all claims that allow the switch between string or array and have a marshal method on that. Either way it sounds like more code to maintain. I would abstain until it's proven to be absolutely necessary by the OP or others.

You're right. As the RFC even uses MAY and not SHOULD it's even less necessary.

[Kunde21]

The context here are FAPI compliant auth servers at financial institutions that take a very strict reading of the FAPI part 2 Section 5.2.3:

In addition, the confidential client:
...
10. shall send the aud claim in the request object as the OP's Issuer Identifier URL
...

The token exchange fails for any value of aud that does not match the issuer (in some cases) or the token endpoint (in the rest).

[muhlemmer]

And a FAPI compliance test is failing with a single value was set to an array? Or is this a theoretical discussion?

[Kunde21]

This is an active, production system that is being integrated upon. The oidc server is not going to change in this scenario.

[muhlemmer]

After some digging we found this conformance suite discussion.

Practically, the FAPI test suite introduces the error as it gives the idea the Audience should be a string. But that's a bug is the suite. Meanwhile, what I get from this comment is that the conformance test automatically flattens the array and therefore accepting implicitly a single element array during RP testing.

---

If it helps, I would be open to a PR that implements a Marshal method on the oidc.Audience type. And hope there are no OPs out there that only accept arrays.