Add possibility to use custom field in JWTHeader

[MFranceschi6]

Is your feature request related to a problem? Please describe. In some real usecases (search for Step 2: Form the JOSE Header in the link) it's required for the JOSE header of a JWT to have more fields then the one supported by this library.

It's not a real problem when we need to decode them, but we have to implement some hacky way for the encoding part (like copying the whole JWTSerializer implementation and directly use it)

Describe the solution you'd like Make the JOSE header an interface that can be passed to the sign and verify function of JWTSigner. Make the current JWTHeader implement the new interface and use it as default.

Describe alternatives you've considered Make the JWTSerializer public. Don't really like this way...

Additional context I do know you are going to release the new breaking version of this library, so it could be the right time to explore this feature.

Also it would be really nice to support the b64 header out of the box. It should be pretty easy just few changes inside the implementation of the non public JWTSerializer struct

[0xTim]

@MFranceschi6 do you have any examples of JWS tokens using b64? (Specifically where it's set to true)

[MFranceschi6]

Hi, the b64 set to true is basically the default form of a JWT. The meaning of that header is: If true the signature is calculated from the normal base64url(header) + '.' + base64url(body) if false the signature is calculated from base64url(header) + '.' + body

You can try this with jwt.io Use this as the header

{
  "alg": "HS256",
  "typ": "JWT",
  "crit": ["b64"],
  "b64": false
}

In this case the output of jwt.io is a detached jws signature which is also the use case for that header.

For instance, in the real use case of the UK openbanking, the detached jws signature of the body is to be added to one header for non repudiation reasons.

If you change the b64 to true then the output of jwt.io is a normal jwt.

I do agree that this is more linked to Json Web Signatures than Json Web Tokens.

Also, this is not the place but are you up to consider a whole implementation of the JOSE standard? Maybe take the JWS part of this library make a JWE library and then use those libraries for the JWT library?

Sorry for the off topic

[ptoffy]

@MFranceschi6 the issue arised here, as in the RFC it says

For interoperability reasons, JSON Web Tokens [JWT] MUST NOT use "b64" with a "false" value.

As you said, this is a JWT lib rather than JWS so not sure whether it's a use case we want/need to support

[MFranceschi6]

I do understand the situation, it was worth a try.

If the main request of this issue is being considered is more than enough.

Thanks

[ptoffy]

Implemented in #129