I’ve been going over the OAuth documentation and while I understand how to get tokens, I have several questions about maintaining them:
Twitch suggest to validate the tokens on a regular interval, but this isn’t really possible in an application with many users (and many of them might be inactive). Is there an alternative? Like validating only before I make an API call?
What is exactly the meaning of a failed validation? Does it mean that the user canceled the authorization? Can it mean that the token expired (but the app is still authorized)?
Twitch suggest that on a multi threaded app, you should refresh the token synchronously in order to avoid race conditions and the like. I agree. However, I have a hard time thinking of a good approach on how to do it. Anyone has a suggestion on this? My app uses Redis, if it’s any help.
I know I’m asking a lot, but I’ll be very grateful for any information. Thanks!
Validating on a regular interval depends on your app and how validating is relevant to your implementation of the Twitch API. I do not disagree that what you describe is permissable.
How do I know what is the reason for a validation failure then? The documentation doesn’t really describe what responses the validation endpoint can give.
Does it matter? Regardless of the cause of the failure, the result would be to log out the user as they’re no longer authorised so you have to send them back through your auth flow again (which if they’re still connected to your app will likely be transparent to them).
If you need to know the reason why, well Twitch tell you when a token expires when it gives you the token, it’s you’re job to refresh the token before that point, or send the user through the auth flow again. If you can’t refresh the token, or if a token is invalid before its expiration, then assume the user disconnected from your app, log them out, and force them back through the auth flow if they wish to use your app again.
There are 2 simple ways to perform validation for logins. Either refresh their tokens frequently while they are logged in, or just have a short session time after which the user has to go through the auth process again (if they’re connected all that’ll happen is you’ll send them to Twitch who will send them right back to your redirect url, if you include the users intended path as a state param to Twitch then you can even redirect them directly to the page they tried to access, making the auth process invisible to the user, other than a slight extra load time).
As for the best way to handle refreshing tokens, that’s entirely up to you and your app, there are many ways to handle it and whats best for you and your use case we don’t know.
I thought it matters because Twitch suggest to refresh reactively and not actively, so knowing when a failure happened because of an expiration seemed relevant. Am I wrong in thinking that?
Like I said, Twitch tells you the expiration of a token when it gives you the token, so you know when it is due to expire. If you want to wait for a token to expire and fail a validation check or API call before refreshing, that’s your choice, personally I refresh all my tokens before expiration which both checks the user is still connected to my app and prevents any API failures due to invalid authentication.
My app runs in Node.js in a cluster, so multiple processes might make a request to Twitch at the same time. If I go the way Twitch suggest and only refresh reactively, when multiple processes will make a request at the same time and fail, they will all try to refresh the token, which is bad. This is what I’m trying to understand how to avoid. Is that enough information?
