Yes. Nobody provided any solution to the question right? The JWKs you provide are invalid.
Ok let me dig into that and get back to you soon!
Hi, any updates? At-least the rational/reasoning from your engineers on why there is a non-standard implementation?
Hi, for me this is quite unacceptable. I do not mean to be rude or nonconstructive. But we pay money for Auth0 (I think it is a good service in general) to be able to “forget all Auth-stuff”. For me it is quite remarkable that our library is more picky than our Auth provider. The standard library that we use cannot be coerced to accept this invalid value so, as it stands now, we will be forced to write our own library or change service from Auth0. The latter would be sad since I like it in general.
I’m not a security expert and how do I know what other inconsistencies or incorrect implementations exists that open us up for potential attacks? I use Auth0 since I trust that you have thought on all nitty-gritty details that we would’ve missed if we implemented a solution in-house.
I hope this will be resolved quickly.
I’m having issues with this, please provide a rationale/fix
I am also having issues with this. Please look into this.
Hey there! Sorry for such huge delay in response but there are a few people who reported that and our developer support team is still researching that! I’ll let you know once I have some more info!
Hello everyone. I’ll be taking a look at this next week–I’ll discuss with engineering as appropriate and post an update here.
1 Like
Thanks Matt! Also our Developer Support Team is also researching it.
1 Like
Hello,
I looked into this and it appears we are base64 encoding the hex representation of the SHA-1 digest instead of the binary (openssl returns the hex by default if you ask for a cert digest). Producing the x5t is a matter of
(assuming x5t.der is a DER-encoded X.509 cert)
$ openssl dgst -sha1 x5t.der
vs
$ openssl dgst -sha1 -binary x5t.der
And then base64 encoding the result. The latter command outputs binary 20 bytes in length.
I have an inquiry in to our engineering team about this–I’ll post an update here when they respond.
Matt MacAdam
Senior Developer Support Engineer
Auth0 (Bellevue, USA, Pacific Time)
1 Like
Hi folks,
Thanks for your patience. Engineering has acknowledged this is a bug. We base64 encode the hex digest of the cert, when we should encode the binary digest of it.
Unfortunately there’s no ETA on a fix. If you’re a paid customer and haven’t reported this yet, please open a support ticket explaining how the bug affects you. Engineering can prioritize their work best when they fully understand how many customers are affected and to what extent. If you’re using the free tier we also want to know if you’re affected–please start a new thread explaining how the bug affects you and our community moderators will relay your report to engineering.
Thanks!
2 Likes
Any compliant JWK parser will barf on this.
Removing the offending “x5t” is a valid fix, as it is an optional field.
I am a paying customer that has notified you about this.
Hi everyone,
I have an update from engineering. We’re working on a fix for the thumbprint issue. Since this may be perceived as a breaking change for some users we won’t automatically update the value for all tenants, but once the work is complete:
- New tenants will assert a correctly formatted x5t in the JWK
- Existing tenants will have the option to migrate to a correctly formatted x5t
I don’t have an ETA yet but I’ll post here once we have one, or once the fix is live, whichever happens first. 
2 Likes
Hi everyone,
I’m happy to report that today we released Singing Key Rotation, which includes a path for fixing the x5t value in your JWK:
Your existing keys will continue to have an incorrectly formatted x5t, but if you rotate your signing key the new key will have a correct x5t. Newly created tenants will also have a correctly formatted x5t.
Thanks!
2 Likes
Thanks for providing that info Matt!