This post applies to all developers who are using the OAuth2 login flow as authentication for their service’s protected resources, in addition to any Twitch resources accessible via scopes.

As a courtesy, we wanted to post a reminder that we require applications using Twitch OAuth2 for login purposes to validate their access tokens on a recurring basis. That is to say, if your application is using Twitch as a form of authentication (i.e. verifying that a user is who they say they are on your platform), you should conduct hourly validations of tokens. Additionally, you should validate access tokens prior to processing requests that access or perform mutations on sensitive information of users. We ask that you implement this validation as soon as possible if you have not done so already.

This is important because of how OAuth access tokens work and the end user’s expectation of OAuth session control. For example, a user who opts to disconnect your integration from their Twitch account can do so from their account settings on Twitch. When a user disconnects from an integration, all OAuth access tokens between that user and that integration are invalidated. In this scenario, the expectation is that OAuth access tokens are tied to sessions on third-party applications; as such, any existing sessions between the disconnected user and those applications should also be invalidated.

Twitch does periodically conduct audits for the security of our mutual users. If we discover an application that is not re-validating access tokens, we will reach out and work with the developers to resolve the issue. If the issue is not resolved, we may take punitive action, such as revoking the developer’s API key or throttling the application’s performance. We certainly prefer the former; your success is our success!

Our Authentication Guide has been updated to make this requirement clearer. If you have any questions, please respond below, start a new topic, or take advantage of the chat server.

Personally, I avoid storing tokens on my server wherever possible. If all I do is verify the token and then discard it, does it still violate these new guidelines?
In other words, do I need to start storing tokens and verifying them hourly?

The point of revalidating the tokens isn’t necessarily to keep the token alive, but to delete the users data from your server if the user so chooses to delete the integration. It’s the easy way for a user to ensure the safety of their data.

I’m curious about @BarryCarlyon s concern though, as I’d also be worried about the rate limit.

The wording is kind of weird all around. Such as “applications using Twitch OAuth2 for login purposes”

My site uses its own username/password combo, but relies on a “Link your twitch account for certain functionality”. So I’m not sure how that applies.

This is a really bizarre requirement from Twitch. No other OAuth provider has this requirement. If the user revokes access, the token should simply stop working. The closest I’ve seen is at Facebook where they have it lets you know when a user has revoked access.

Currently we’ve got approximately 10 million Twitch authenticated users in our platform. It’s going to be very vexing for us to run ~3000 checks per second continuously and I’m sure Twitch isn’t going to appreciate it.

Currently we’ve got approximately 10 million Twitch authenticated users in our platform. It’s going to be very vexing for us to run ~3000 checks per second continuously and I’m sure Twitch isn’t going to appreciate it.

Unless those 10 million users are all active on your platform at the same time, you don’t need to check the validity of their token. When they’re actively using your app you need to ensure that they haven’t revoked the token some time between logins, if they’re not currently using your app then you can send them through the OAuth process during their next login to ensure it’s valid at that point.

if they’re not currently using your app then you can send them through the OAuth process during their next login to ensure it’s valid at that point.

Thats basically what I do, and I don’t use/store the token after login, I keep it long enough to start a session after ID’ing the user. And in light of some recent tests replacing the whole auth loop with something much much nicer

We replied to the email about doing this but there’s been no response for ten days. Is there some way we can speak to someone about our specific scenario and what we propose to build? I can’t help but feel that I’m misunderstanding the requirements here because no other OAuth provider has required this.

The two main concerns are:

Our app allows for a user to be logged in to multiple (E.g. Facebook, Instagram, SoundCloud, Twitter, etc) different accounts. Just because they revoke Twitch access doesn’t mean they would want to be logged out of our system entirely.

It seems very strange that we need to continually validate tokens. Would they not simply stop working when the user revokes access?

Our app allows for a user to be logged in to multiple (E.g. Facebook, Instagram, SoundCloud, Twitter, etc) different accounts. Just because they revoke Twitch access doesn’t mean they would want to be logged out of our system entirely.

It seems very strange that we need to continually validate tokens. Would they not simply stop working when the user revokes access?

So don’t log out the user then if they are still logged in via other valid means?

You don’t need to continually validate tokens, only when they are using your site. It doesn’t matter if a token is invalid when they are not active on your site.

Yes, the tokens will stop working when the user revokes access, but this isn’t about using access tokens to access API stuff, it’s about using Twitch’s OAuth process to log a user in to your site, so if you’re doing JUST logins, and not accessing the API then without validating the token you would have no idea if the user has revoked the token or not, and due to session cookies they may still be using your site when you should be sending them back to the login screen (unless they’ve also logged in with a non-Twitch OAuth process, in which case how you handle that is up to you).