How do I set unregistered claims without using the deprecated unregisteredClaims or addClaim methods?

[ChrisPenner]

The previous way to handle unregistered claims was to use these methods:

Which have both been deprecated, stating to "use a sub-type", which I assume means to define an instance of HasClaimsSet for some type I define;
However, there doesn't appear to be any way to actually provide unregistered claims for a custom type, since there's no lens for unregistered claims in HasClaimsSet to implement in the instance, and there's no way to create a ClaimsSet record otherwise since the _unregisteredClaims field of ClaimsSet isn't exported.

I suppose I could use the FromJSON instance of ClaimsSet to implement HasClaimsSet without using any deprecated methods, but that definitely seems like taking the long-way around and would involve introducing a possible failure point in the decoding step.

Perhaps was an claimUnregistered :: Lens' a (Map Text Value) accidentally omitted from HasClaimsSet when the other methods were deprecated?

Thanks!

[frasertweedale]

The design decision I took was that non-RFC7159 claims processed (or produced) by an application should be defined as first-class fields of subtypes. There is a simple example at the top of https://hackage.haskell.org/package/jose-0.10/docs/Crypto-JWT.html (data Super). You should not need to use instance FromJSON ClaimsSet to define instance HasClaimsSet for the subtype. You also need to define FromJSON (if verifying) and ToJSON (if producing) for the subtype.

How you get and set the additional fields (claims) in the subtype is up to you. Lenses, ordinary field accessors, whatever you prefer. But there will no longer be a Map of unrecognised/unregistered claims.

[ChickenProp]

I'd suggest adding some function ClaimsSet -> Aeson.Object to help with this. I think the standard way to write a ToJSON instance for things like Super will be "run toJSON on the base ClaimsSet, and add some fields to the Object it gives". But that means we need to handle the possibility that toJSON doesn't give us an Object at all. In your example you silently ignore in that case, personally I'd choose to error, doesn't make much difference because I don't expect it to happen. But having a type level guarantee that it won't happen would feel much nicer.

[ChickenProp]

Though honestly, I'd also request un-deprecating this. IMO the boilerplate of defining the new type is worse than using addClaim/unregisteredClaims. And haskell-servant/servant#1717 sounds like "some users are going to essentially need to re-implement these things anyway", in which case I feel like it might as well be exposed from here?

Though I could imagine the interface wants to change. Maybe something like, ClaimsSet has just the standard claims; you're encouraged to subtype it if you want custom claims; but you can use ExpandedClaimsSet if you want custom claims that you don't know up front.

[ChrisPenner]

I'd tend to agree that using addClaim with unregisteredClaims has been more intuitive for me. Presumably there are others who find the new system makes sense, but for myself I find the new system rather confusing, and ended up wrapping it in a different interface in my application in an attempt to prevent mistakes when working with JWTs in my webapp.

[and-pete]

Am also attempting to wrap my head around the new subtyping approach beyond the doc's Super example case of a single unregistered isRoot claim.

So for some arbitrary case where we'd include multiple unregistered claims...

Is the expectation that we'll build our data type(s) as follows:

data User = MkUser
  { userId :: Word64
  , userName :: Text
  , userIsAdmin :: Bool
  }

-- and nest it alongside the `ClaimsSet`?
data UserWithClaims = MkUserWithClaims
  { jwtClaims :: ClaimsSet
  , jwtUser :: User
  }

...for a payload that might look something like this?

{
  "iat": 1754377801.0854652,
  "exp": 1767230625.1234567,
  "user": {
    "id": 8008135,
    "name": "ree",
    "is_admin": true
  }
}

Or more like the following single data type and flat JWT payload?

data UserWithClaims' = MkUserWithClaims'
  { jwtClaims :: ClaimsSet
  , userId :: Word64
  , userName :: Text
  , userIsAdmin :: Bool
  }

...and say...

{
  "iat": 1754377801.0854652,
  "exp": 1767230625.1234567,
  "id": 8008135,
  "name": "REEEEEEEEEEEEEEEEEEE"
  "is_admin": true
}

(I do recognize here that those pairings of data type with JSON encoding are arbitrary and that the UserWithClaims holding the nested User type could have also been encoded in the second flatter manner)

[ChrisPenner]

For those looking for an alternative interface, here's what I ended up doing:

• I added wrote a new class which works with a simple isomorphism to a Map of claims
• Implemented HasClaimsSet for that map of claims
• Added a StandardClaims type which implements the class for handling the standard claims

Feel free to copy/alter the approach from there;

https://github.com/unisoncomputing/share-api/blob/173b85254c0a8f8f28f00ccd64a916003fd4a8fa/share-auth/src/Share/JWT/Types.hs#L74