Option to add custom claims to the generated jwt

[Zetanova]

What motivated this proposal?

I would like to use some well known jwt claims for configuration the nats client itself. To generate the jwt and sign it programmatically has no issues.

But to generate one user with some claims like 'aud' or 'act' over nsc cli it seams not easy possible.

What is the proposed change?

To add a optional parameter to the add and edit methods to extend the jwt with custom claims. nsc add user --name <n> --claim aud=my.scope --claim act=host --claim custom="{\"value\": 1234}"

Who benefits from this change?

The jwt can be used as a client confirmation source. Example: ncOptions.InboxPrefix="_INBOX.${jwt.aud}"

What alternatives have you evaluated?

could not find any possibility to extent or use custom jwt with nsc

[aricart]

This isn't necessarily very helpful and introduces possibilities where the audience is not a valid subject token. You can use the user ID as part of your subject options and clamp the JWT to use that user ID. The client will know what its user ID is...

[aricart]

The audience field doesn't have any requirements as it is a standard field in JWT. Subjects on the other hand do. - If you are already decoding the audience at the client level for the options, that also means that you also know what the user ID is so you can set your option for inbox to have _INBOX.userid.>, which is a more deterministic value.

[Zetanova]

How the user is using its custom claims does not matter for nsc or nats-server, nsc simple does not support the usage of custom claims.

It's common to define resource scopes and other claims like mini-profile in a jwt, it makes a creds rollout simpler. (single file)

[aricart]

While I understand that you can decorate a JWT with anything, purposely not exposing all fields - in many cases the server is not looking at the Claim itself and they are just internally validated. Adding additional metadata is fine, but the issue is exposing it with the general tooling. If you have such type of requirement, likely generating the JWTs directly with API is more expedient. I don't agree that we should add additional options to the user JWT as that would increase the tooling requirement (not thinking of just nsc but other things that generate users)