Currently it is possible to extract the payload using decode, but this does not include the header information.
For the use-case of a token which specifies the name of a key used to sign it, it is important to be able to extract this key name from the token in advance to know which key to provide to decode for verification. Specifically, this relates to Google's "web sign in" JWT (where 2 keys are valid at any time to allow key rotation). This could be handled by trying both keys, but that is inefficient and unnecessarily reduces security.
Alternatively this library could be updated to optionally consume a dictionary of key-name -> key, and check the kid property of the header.
From what I can tell, the only existing option is to manually decode the header part of the token, which seems wasteful since this library already has the necessary code.
Currently it is possible to extract the payload using
decode, but this does not include the header information.For the use-case of a token which specifies the name of a key used to sign it, it is important to be able to extract this key name from the token in advance to know which key to provide to
decodefor verification. Specifically, this relates to Google's "web sign in" JWT (where 2 keys are valid at any time to allow key rotation). This could be handled by trying both keys, but that is inefficient and unnecessarily reduces security.Alternatively this library could be updated to optionally consume a dictionary of key-name -> key, and check the
kidproperty of the header.From what I can tell, the only existing option is to manually decode the header part of the token, which seems wasteful since this library already has the necessary code.