The parsehash function seems to not accept HS256 in v8
with message "invalid_token" "Algorithm HS256 is not supported. (Expected algs: [RS256])"
var token = webAuth.parseHash(function(err, token_payload) {
if (err) {
console.error(err)
}
if (token_payload) {
history.replaceState({}, document.title, '/');
console.log("Id Token", token_payload);
createCookie('auth0jwt', token_payload.idToken, 365);
}
});
<script src="https://cdn.auth0.com/js/auth0/8.0.4/auth0.min.js"></script>
Yes, this behaviour is correct and the idea is to enforce the usage of RS256.
This new version provides token signature verification and nonce generation/verification to avoid CRSF which is not possible with HS256 (for those tokens, you will need to expose your client secret which you should never do).
@glena I understand the security implications here, but there is no clear upgrade path given. This is very frustrating.
@ianks sorry for the all the troubles but as a major version you might expect breaking changes and some friction and we are working on a migration guide in our docs.
About the upgrade path you can keep using v7, since it also works and we still support that version (we will notify properly if this changes).
If you still want to use v8 you can avoid the parseHash method, since it only works for RSA, and just parse the tokens from the url hash (you can check how we do it here and also here)
And finally there is the option to switch how the id_tokens are signed from HS256 to RS256 for your specific client:
JsonWebToken Signature Algorithm to RS256
Just remember, if you are validating the token in another place you might need to change that validation too.
Hope that helps!
Thank you @hzalaz. The confusion stemmed from the fact that I upgraded Auth0.lock, which is turn upgraded this library. Maybe the Auth0.lock should have been less loose about their versioning, since it was breaking in this case. Either way, thank you for the guidance! I will have to figure out a way to do some backwards compatible validation for this at some point, but for now I am sticking with [email protected]
@ianks if you are using Lock you don't need to do anything since we didn't remove support for it in Lock, we just removed the support in auth0.js. We had an issue where we weren't handling that flow properly and it was fixed.
I think new accounts should default to RS256.
@hzalaz if we were using auth0/express-jwt to validate our token, it breaks when the switch to RS256 is made, throwing an 'invalid algorithm' error. Any solution to this?
@RobinJayaswal the only solutions are:
id_token in some way if you are relying on it and since HS256 relies on a shared secret this should be done on the server side.You can also migrate your backend to validate the token with RS256 but that will take a bit more of work on your side.
@hzalaz so within the next 6 months auth0/express-jwt should have figured out the issues with verifying the token with RS256?
@RobinJayaswal it's not that it needs to figure out how to do it. it just that you need to configure the check to validate RS256 instead of HS256 since it already support that. What I meant before is that you need to perform the change in your backend
@hzalaz can you point me to a reference on how to do that? I do not see it in the documentation.
We have a sample: https://auth0.com/docs/quickstart/backend/nodejs/03-authenticate-rs256
Also in auth0/express-jwt README there is the following mention
This module also support tokens signed with public/private key pairs. Instead of a secret, you can specify a Buffer with the public key
var publicKey = fs.readFileSync('/path/to/public.pub');
jwt({ secret: publicKey });
where you specify the public key to validate the RS256 signature, you can also validate other claims too. The quickstart has also the feature to download the key automatically.
I ran into this problem today in my first attempt at using Auth0, using the auth0-react-samples github project. If I had not quickly found this Github issue, I probably would have walked away, thinking it too rough around the edges.
I am not quite sure what's happening here. I've understood the implications of using HS256 vs RS256, but I am also using parseHash with auth.js version 8.7 which seems to work fine, even if my client/API combo is configured to use HS256.
If I understand correctly, parseHash parses the fragment part of the URL and extracts various tokens and information, also validating the tokens.
In my app I am using id tokens (client stuff) and access tokens (for my backend API) and both clients and API are declared in auth0's dashboard to use HS256. Still, I am using parseHash both in my silent auth page and in my main SPA after being redirected from login and parseHash works.
Am I missing something?
Thanks
Most helpful comment
@ianks sorry for the all the troubles but as a major version you might expect breaking changes and some friction and we are working on a migration guide in our docs.
About the upgrade path you can keep using v7, since it also works and we still support that version (we will notify properly if this changes).
If you still want to use v8 you can avoid the parseHash method, since it only works for RSA, and just parse the tokens from the url hash (you can check how we do it here and also here)
And finally there is the option to switch how the id_tokens are signed from HS256 to RS256 for your specific client:
JsonWebToken Signature AlgorithmtoRS256Just remember, if you are validating the token in another place you might need to change that validation too.
Hope that helps!