I have a quick question regarding key management with Twitch’s Oauth 2. I think my question is more general, but you never know if the policy is different on the Twitch side.
Do I have the right to use several access_token in parallel for the same user, same scope and same application?
I notice that if I go through the authentication process several times, I get different access_token and refresh_token all the time. I do not have the impression that obtaining a new access_token invalidates the old nor the old refresh_token. So I can thus completely independently use and renew each of the keys obtained in this way?
My initial problem was that I had several different applications that will have to call the API and have their own validation management and renews tokens. So I told myself that if one of my applications renewed its access_token and that it was used by the second, that would be a problem. But suddenly the two access_token obtained in two times does not conflict?
Thank you in advance for your reply
PS :
Besides, I followed your advice and I go through the token validation ednpoint before using them
Additionally if you are using multiple tokens for the same user, with commands being issued from the same server, that can be seen as an attempt to circumvent rate limiting, which you are not allowed to do.
Each new auth loop (redirect to Twitch, user accepts and comes back to your callback) will generate a new token.
But there is a limit on the number of tokens you can have active for a given client ID/userID pair, so if you generate enough in this way, the oldest tokens (and refreshes) will just stop working.
Generally speaking you send the user via the oAuth loop, and store it in a database with a unique key for userID/scopes on the token, in case you need to run two keys with different scopes, but again if you generate enough keys the oldest keys will get murdered. So in reality you should manage a single key for a user, and lump all the scopes you need onto one key.
I understand, however my two applications cannot communicate well. One is a bot for discord which can interrogate the API and the other is the bot rated TMI which may also want to obtain information on the API.
It is a rather complex problem of blows.
The solution to create two applications on the Twitch side, with different client_id and client_secret is not good either I imagine?
If your access token(s) are stored in a database, (and everything is on the same server for simplicity), then both separate processes can read the token from the database, and you use one service (or the other) or make another service for Key management.
Which comes back to the Web portal I suggested in the other thread.
Web Portal - manages generating and refreshing keys, stores keys in database (or flat file)
Discord Bot - reads the key to use from database (or flat file)
TMI Bot - reads the key to use from database (or flat file)
Then you are managing two clients and making things harder
