New Secret invalidates the previous client secret. It does not explicitly say that already-issued access tokens are also revoked. Registration documentation
Individual access tokens can be revoked, but the documented operation requires the specific token. It does not describe an app-wide “revoke all” option. Revocation documentation
If existing tokens remain valid, is there a supported way to revoke all tokens issued for this application—including tokens we cannot individually identify—without deleting the application?
Would that process affect Twitch account sessions or user authorizations?
What propagation delay and verification steps should we expect?
Whats the problem you are actually trying to solve?
This looks like half of an AI output response so on context I’m not sure whar you are asking or trying to do here.
To my knowledge revoking/reset the client secret will do that/revoke all tokens. (Which I’ve not personally tested), but that does differ to what the oAuth RFC states (but it’s been a hot minute since i’ve read the RFC’s).
Either way, if not any remaining (user) access tokens remain active till expire which for code flow that uses the secret is 4 hours. And the refresh token won’t be valid to get a new one anyway (or in the case of a breech the attacker won’t have the new client secret to get tokens with).
We’re addressing a potentially exposed Twitch application client secret. We’ve rotated it, but want to understand whether access tokens issued before the rotation could still be used.
Our integration uses the client-credentials flow for app access tokens, rather than user authorization-code tokens. The concern is that someone with the old secret might have obtained an app access token before we rotated it, and we wouldn’t know that token’s value.
Does resetting the client secret invalidate those already-issued app access tokens immediately, or does it only prevent the old secret from obtaining new ones? If existing tokens remain usable until expiry, is there an application-wide revocation option?
That’s the specific gap we’re trying to close—not recovery of user refresh tokens. Thanks for helping clarify it.