jwtk/jjwt

Suport Array of String for Audience

Closed this issue · 6 comments

From the JWT specification, the Audience should accept a array of strings. Whould be nice a methot setAudience that accept a array of Strings and put this attribute as array on JWT
As a workaround, I'm setting this as a claim attribute:

String[] aud = { "aud1", "aud2" };
Jwts.builder().claim("aud", aud);
...

Generated payload:

{
  "iss": "issuer",
  "aud": [
    "aud1",
    "aud2"
  ],
  "iat": 1443461450
}

From https://tools.ietf.org/html/rfc7519#section-4.1.3

4.1.3.  "aud" (Audience) Claim

   The "aud" (audience) claim identifies the recipients that the JWT is
   intended for.  Each principal intended to process the JWT MUST
   identify itself with a value in the audience claim.  If the principal
   processing the claim does not identify itself with a value in the
   "aud" claim when this claim is present, then the JWT MUST be
   rejected.  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.  The
   interpretation of audience values is generally application specific.
   Use of this claim is OPTIONAL.

It would be good if the requireAudience method could also work with arrays.

@jebbench: For requireAudience("a", "b") would that mean

  1. requires "a" or "b" to be in the audience
  2. requires "a" and "b" to be in the audience
  3. requires the audience to be exactly [ "a", "b" ] (in that order?)

Maybe we'd need more than one method (with the method name making it clear what it looks for).

@thiloplanz Sorry - I wasn't clear, I meant for the requireAudience method to support looking for a single audience from an array in the token.

{
  aud: ['a', 'b']
}

requireAudience("a") -> True
requireAudience("c") -> False

Yep, this should be supported, as per the spec. Thanks for the issue. Pull Requests would be much appreciated!

This is a particularly irritating piece of the spec...is it a string or is it an array? To not break things, you need to serialize a single audience as a string, because some implementations are going to fail to verify if it is an array.

I've made a PR #238 that, if it's accepted, would add support for string arrays in audience attribute without breaks the current functionality. The idea behind the PR is to handle both a simple String and a String array.