JWSInvalidSignature on token verified by jwt.io

[mackler]

I generated a token (several actually) to use for testing a PostgREST application, but I am neither able to get it to work nor to figure out why.

This token: eyJraWQiOiJ0ZXN0IiwidHlwIjoiSldUIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJhbGljZSIsImF1ZCI6Ijk5amV5MEZEYW5SM2NKU09WTVNWMzQ4WDRpemttWkp4IiwiaHR0cDovL3Bvc3RncmVzdC9yb2xlIjoibm90ZXNfdXNlciIsImlzcyI6Imh0dHBzOi8vbWFja2xlci5vcmcvIiwiZXhwIjoxNTQxNzMwMjg1LCJpYXQiOjE1NDE2ODcwODV9.JHnpVP_LJwnx6xKB9_ssY0tWQ_ncFtf6XrWei3kk9Zt91avCCwN2GlPIHV95NDRQOcdGbFkKkvPZLXg51KC8dD_F6v0r_exUwj76mpGMvgH5h3KcrXcSRwhsJIML2naLhshygbt6oJQOYY_UW1yUuIMAmlcco_MYGQVbrWsIX5isvevzWTzHSIZwXdxg6tVEM-cVGtWemA0oqqf92fJAroN6tt0banl4r1yNmzsSMsnSoNrt-18ONTVC5R93zXvr-enGm8x4oT961A-KS5ebiWp1tHe4XT9B2UYMRuqS6zod_zuQgeKAC-PKT1ARPWKL6QXcEclvqwMKlS07y8v9Eg

signed with this key: {"alg":"RS256","kty":"RSA","use":"sig","n":"AJik-7YNJOYkMmAPtUvWzXzzPL-3I63b_tiGfJCTPsawL3fmGh3xfjPBMS-ZCivCKFY_MS35M0RwrWW8I5lQ0qsUO1BPyiwDCJiT8eir5qL8RgBeiVA_-jVZeLF2EE5hK3qiPj1d9kaSzSteZB6rxfRL9AkDbKQfdUfI8_E-fnP8cfRtNY1PYtVAfDiAC4-HSAbeXoT0uSSvfiZj7TSusjnTjHeOGYFLQ4NItjd7xxMib32ti7q4QRnUACsUZmKmJtsC7N20uxxas5EfrsHgpOiN4-Lr5-D82Yqrln3Ksz8_gHdDMXtLUCjQMdSoVOEa0fVA3HjKv55ZMZ7VIKWMvtc","kid":"test","e":"AQAB"}

verifies on jwt.io.

Unfortunately when trying to use it, PostgREST returns a 401 status along with a response body of {"message":"JWSError JWSInvalidSignature"}. A command-line invocation of jose-example jwt-verify with the key, token and audience as arguments says only

jose-example: Maybe.fromJust: Nothing

I'm new to both Haskell and JWT, so maybe I'm missing something obvious. Is there a way to get the jose-example jwt-verify command to give me any more information about what the precise cause is? I generated the token and key using the auth0 java-jwt library. Actual tokens from the Auth0 service do work and I've tried to make my token look as similar to the working ones as reasonable.

I will thankfully welcome any ideas for how to approach this problem given my formidable inability to understand the hs-jose source code.

[frasertweedale]

@macker: the JWK is not valid. It contains a leading null byte in the base64url-decoded "n" parameter. According to https://tools.ietf.org/html/rfc7518#section-2:

Base64urlUInt The representation of a positive or zero integer value as the base64url encoding of the value's unsigned big-endian representation as an octet sequence. The octet sequence MUST utilize the minimum number of octets needed to represent the value. Zero is represented as BASE64URL(single zero-valued octet), which is "AA".

Agree that the error message is quite opaque and I will try to improve it (therefore I'll keep this issue open for now).

In the meantime you should raise bugs against jwt.io and whatever tool you used to generate the JWK.

It should be trivial to repair the key. (decode the byte array in "n" param; drop the leading null byte; re-encode it and save the JWK with the updated "n" value).

[mackler]

whatever tool you used to generate the JWK.

um that "tool" would have been my own code. "How hard could it be to make a JWK?" I thought, "It's just JSON!" Okay, I'm now using the Nimbus library and it's working swimmingly. Thank you for you prompt and accurate reply--and correctly-validating library. My apologies for distracting you with this.

[frasertweedale]

@mackler no worries mate. It's good to be aware of possible interop issues. And even better to be aware where the error messages etc from hs-jose are not up to scratch. Granted, the example programs are just simple demos I knocked together but doesn't hurt to improve them. I'm pushing a few commits to master to improve the error messages and document in the README the behaviour w.r.t. leading null bytes.

Don't feed bad, JOSE is a complex spec. I'm sure I've got it wrong in plenty of places too :)

[frasertweedale]

Commits to address this issue:

• 88e3639 example: improve error reporting
• ad6ff4b improve error reporting when parsing JWKs
• 89b03ad README: add note about invalid JWKs with leading null byte

Closing this issue now.