Feature: Broader assumptions on failed refresh requests

[soofstad]

Failed refresh requests are not always identified to be caused by an expired refresh_token.

The way this is handled today is too brittle, and requires manually maintaining a list of known error responses from all possible authentication servers.

Suggestion:
Make a broader assumption like if the refresh request fails with a "400" (40x?) status code, that it's caused by an expired refresh_token.

[sebastianvitterso]

I'm gonna vote against a general 40x check at least. A 404 should not happen if the refresh token being expired, and the same applies to 403. I'll accept arguments that 401 might be ok, since technically you're no longer authenticated when this happens, but a 400 makes much more sense.

Still... we're working with a plethora of OAuth-providers, so maybe we can start with 400 and see if anyone creates issues that their providers uses 40x, and then add one by one?

[prabhurajshell]

@soofstad Side question related to expiry of tokens : I don't see anything in the documentation regarding options to refresh tokens on expiry. How do we check if a token is expired/valid or renew it when required?

PS : Thank you for this simple and effective package. :)

[soofstad]

@prabhurajshell You should not have to check for expiry, nor do a manual refresh.
The library will refresh the token in the background as long as the refresh_token is valid. When (if ever) the refresh_token expires, it will trigger the onRefreshTokenExpire-event which you can handle. Usually by doing a page refresh, triggering a new login.