# Manage more one access\_token for unique user and application **URL:** \ **Category:** API\ **Created:** [April 9, 2020, 12:10pm UTC](https://staging-discuss.dev.twitch.com/t/manage-more-one-access-token-for-unique-user-and-application/24883 "2020-04-09T12:10:56Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Sylvanus](https://d1d6mrmdu7ztse.cloudfront.net/user_avatar/staging-discuss.dev.twitch.com/sylvanus/32/8271_2.png) [@Sylvanus](https://staging-discuss.dev.twitch.com/u/Sylvanus)\ **Post date:** [April 9, 2020, 12:10pm UTC](https://staging-discuss.dev.twitch.com/t/manage-more-one-access-token-for-unique-user-and-application/24883/1 "2020-04-09T12:10:56Z")
Hello Hello 🙂 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 🙂 ---
**Author:** ![BarryCarlyon](https://d1d6mrmdu7ztse.cloudfront.net/user_avatar/staging-discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://staging-discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [April 9, 2020, 12:17pm UTC](https://staging-discuss.dev.twitch.com/t/manage-more-one-access-token-for-unique-user-and-application/24883/2 "2020-04-09T12:17:14Z")
> [@Sylvanus](#): > > Do I have the right to use several access\_token in parallel for the same user, same scope and same application? Sure, but in practice that is a bad idea. 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. > [@Sylvanus](#): > > 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? 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. ---
**Author:** ![Sylvanus](https://d1d6mrmdu7ztse.cloudfront.net/user_avatar/staging-discuss.dev.twitch.com/sylvanus/32/8271_2.png) [@Sylvanus](https://staging-discuss.dev.twitch.com/u/Sylvanus)\ **Post date:** [April 9, 2020, 12:19pm UTC](https://staging-discuss.dev.twitch.com/t/manage-more-one-access-token-for-unique-user-and-application/24883/3 "2020-04-09T12:19:54Z")
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? ---
**Author:** ![BarryCarlyon](https://d1d6mrmdu7ztse.cloudfront.net/user_avatar/staging-discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://staging-discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [April 9, 2020, 12:25pm UTC](https://staging-discuss.dev.twitch.com/t/manage-more-one-access-token-for-unique-user-and-application/24883/4 "2020-04-09T12:25:12Z")
> [@Sylvanus](#): > > 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. 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) > [@Sylvanus](#): > > The solution to create two applications on the Twitch side, with different client\_id and client\_secret is not good either I imagine? Then you are managing two clients and making things harder ---
**Author:** ![system](https://d2spem0quai2ol.cloudfront.net/original/2X/0/05909729875cce3b53e59d5561c4d23bb14948fc.png) [@system](https://staging-discuss.dev.twitch.com/u/system)\ **Post date:** [May 9, 2020, 12:25pm UTC](https://staging-discuss.dev.twitch.com/t/manage-more-one-access-token-for-unique-user-and-application/24883/5 "2020-05-09T12:25:15Z")
Closed on May 9, 2020, 12:25pm UTC This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.