Add a formal way to handle different token validation errors

[andreapizzato]

Issue

When you try to call the first Auth0Client method that verifies the JWT token (usually handleRedirectCallback in the guides) you could encounter a whole set of errors, defined in jwt.ts:62. The problem is that they are thrown using a pure Error class also without any kind of matchable code.

This makes developers unable to handle the cases properly, so final users barely know why the application is failing for them.

Proposed solution

I'd like to get a better implementation of this use case, giving developers two ways for finding out what happened:

• Throw the error with a custom class that extends Javascript's Error class which could include a JSON containing at least an enum-defined error code and the expected/obtained parameters in an applicative-useful object;
• Add the possibility of passing an error handling function to the Client's constructor which gets called on such errors with a payload defined as described in the bullet above.

Conclusion

If you want I can provide a PR with the accepted solution(s).

[stevehobbsdev]

Thanks for raising this. The token errors are really for developers to make sure the tokens they're getting are sane and would only normally surface if somehow the tokens you're receiving from Auth0 have been compromised. I'm unsure how handling those in a different way would be beneficial for your end users, but I'm keen to know more about your use-case and the environment in which auth0-spa-js will be running.

If you're using Auth0 as your IdP and not doing anything strange with Rules (like removing important claims) then you shouldn't see any issues. If there are issues, these are more for developers to sort out but I'm unsure as to how handling specific errors can help. LIke I said, would love to hear more about usage.

Add the possibility of passing an error handling function to the Client's constructor

Right now you don't have access to the constructor, only to createAuth0Client. But seeing as that returns a Promise, this can already be handled by either handling catch, or using a try/catch block.

[andreapizzato]

I can see how errors are only for developers, and this is exactly what happens even in the auth0 login page. You see something has gone wrong, but don't enter too much in technical details.

My point is about a formal way to distinguish between those errors. For example: we have an error, the one for wrong client datetime, which can raise when the user PC clock is not in auto-sync and goes beyond leeway time. When this happens, it could be nice to be able to handle this specific error asking the user to check that his computer time is correct. Another example: if the last end-user login interaction was too far in time it could be easy to force the user to login again without even notifying for an error.

My point is: we don't need the user to know the technical failure reason; as for some errors the fix is on user side, it would be nice to have a way to help the user fix the problem and separate those errors from the one you obtain with old/mismatched/fake tokens. I don't expect the library to be able to speak to the user; I would like to have it giving me a better distinction about errors so I can help my users towards a better UX.

[stevehobbsdev]

I think the best way forward with this would be to submit a pull request with the changes that you would like to see, where we can discuss it further. I agree that this would be nice, but we have to do it in a backwards compatible way and the reality is that it's not a high priority.

I'll close this issue for now, but feel free to continue the discussion if needed and I'll keep an eye out for that PR.