Hey @ThStock. Thanks for the contribution, but there are many reasons why we don't allow setting custom claims like that and you can search them in the closed issues' discussions. That method is private because we want to control the type of values that it's set on the token.

@lbalmaceda will a push with the following content have more success?

    public Builder withAccess(Object access) {
      addClaim(PublicClaims.ACCESS, access);
      return this;
    }

Background: I want to access a docker registry with an auth token

• https://docs.docker.com/registry/spec/auth/token/

Like this implementation in go:

• https://github.com/cesanta/docker_auth/blob/dd8ea4b8429b5e31bf102f77fdda866186e2cb6f/auth_server/server/server.go#L316

Changing the name of the claim won't change it's type. It's just the same as your first comment.

I guess your idea is to send the requirements that the docker token must have inside the JWT payload, and then request that docker token from the client. The requirements I see in the go implementation link you shared are strings type and name, and actions which is an array. Because this library doesn't allow you to put map-like structures you'd flatten it like this:

//..
String token = JWT.create()
        .withClaim("dkr.typ", "token type")
        .withClaim("dkr.nam", "token name")
        .withArrayClaim("dkr.act", ["write", "read", "etc"])
        .sign(algorithm);

A valid communication is possible with the following. So the only missing method was withAccess
...

String token = JWT.create()
          .addClaim("access", ImmutableList.of("..."))
          .withIssuer("Some Issuer")
          .withAudience(service)
          .withKeyId("...")
          ...
          .sign(algorithm);

@lbalmaceda Do you think this has a chance?

No. We don't support that kind of structure. You need to convert the "access" claim value to some structure we can support. I've already proposed you a workaround in my previous comment.

Currently supported classes for custom JWT Claim creation and verification are: Boolean, Integer, Double, String, Date and Arrays of type String and Integer.

See: https://github.com/auth0/java-jwt#payload-claims

It seems very odd to me to disallow setting claims of custom data types when creating a JWT, when you can deserialize custom types when parsing/verifying. Why does Claim.as(Class<T> tClazz) exist if there's no way to get custom types into your token in the first place?

The only reason it exists is because people might be using different JWT libraries in other platforms than Java that allow it, and they might actually need to read a specific type of claim using this library. Although that method exists, there's no way to customize the "JSON adapter", so if your class needs specific deserialization logic it won't be possible for you to read it here. If you've read the related issues' discussions then you know we do this because we don't want to tie the library's public API to a specific JSON library, among other things such as the token complexity should be relative small.