When a JWK set is fetched from https://<your-auth0-domain>.auth0.com/.well-known/jwks.json , the x5t field in the response has an invalid thumbprint. It should be 20 bytes, but it is longer.
There was already an issue opened (1), but closed without resolution. This is a bug in Auth0, as per RFC 7517 - JSON Web Key (JWK) .
The “x5t” (X.509 certificate SHA-1 thumbprint) parameter is base64url-encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of an X.509 certificate [RFC5280].
As far as I understand, in Auth0 it is base64 encoding of hex-encoding of the SHA-1 thumbprint, which is incorrect.
Because of this third-party libraries don’t work well with Auth0. This bug also prevents other products from integrating well with Auth0 (2).
Would appreciate if there is proper discussion around this (and not abrupt closing) and resolution.
Sorry for such delay in response! We’re doing our best in providing the best developer support experience out there, but sometimes the number of incoming questions is just too big for our bandwidth. Sorry for such inconvenience!
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.
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!
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)
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.
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.
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.
