You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@hokaccha or @alexjab would you be interested in a PR around this, or do you have any feedback for #72? I'm affected by this as well, and might be able to work on a PR if there was a chance you'd merge it.
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.
The text was updated successfully, but these errors were encountered: