Random 401 Unauthorized on OAuth2 for some users on /oauth2/@me & /users/@me.

[RealAlphabet]

Description

Since the beginning of the year, I've been experiencing a problem with the Oauth2 Discord API. Randomly, Oauth2 tokens return "401 Unauthorized" when I try to retrieve the associated user (after refreshing the token) or the token information with the introspection route. This causes a loop and a denial of service on my API every time a buggy user logs in with his Discord account on my platform. The loop problem has been fixed but I still got Cloudflare Ban 24 hours because of it. There's a huge problem from an OAuth2 data integrity point of view on Discord, I've never seen anything like it. I've tested it several times, even by hand, the route accepts all the refresh tokens I give it, sends me back a new token, but I can't do anything with that token, I have to ask the user to connect and in 15% of cases (I've been monitoring for 1 month now) users simply can't connect to my platform. I had to create several applications and test them in round robin mode to get around the problem...

Steps to Reproduce

I'm not able to reproduce this problem, but it occurs randomly after a few weeks or months and seems to apply randomly to certain users.

Expected Behavior

1. Either the refresh_token is not accepted, indicating that the user has revoked the authorization (and that it really has been revoked from the account settings).
2. That the route returns the information correctly, without errors.

Current Behavior

• The refresh_token is accepted.
• The newly provided refresh_token IS VALID.
• The newly provided access_token IS NOT VALID (INVALID) and always returns 401 Unauthorized for all APIs routes.

Screenshots/Videos

An example of a buggy user. I have to forcibly revoke the token with the route to revoke the token and the user has to reconnect for it to work again. Otherwise, even reconnecting doesn't work 70% of the time for the user.

Please note that I have created 4 different applications since the end of December, so this is not due to the application. I've even tried removing the "guilds.join" scope and leaving only "identify", but the problem persists. I've also bought a new IP address with a very good reputation from my German host, but it's no use.

Client and System Information

N/A

[lsdimagine]

It's hard to debug per the description... We fixed a bug where apps could create several tokens earlier this year, I guess you still experiencing the issue now?

[RealAlphabet]

It's hard to debug per the description... We fixed a bug where apps could create several tokens earlier this year, I guess you still experiencing the issue now?

Yes, I'm currently encountering this issue. I understand debugging can be challenging, and I apologize for any inconvenience. Due to the considerable time it takes for the error to occur, I'm uncertain about its specific trigger.

If it helps, I can reach out to you on the Discord Developer server and provide you with a user ID and a refresh token. Although the refresh token is valid, it will invariably return an invalid access_token. Would this information be useful for your investigation?

[flyingsquirrel1312]

I got the same issue. Our server couldn't get user information by token. But when debugging, we use the token on local, It's successful

[RealAlphabet]

It's hard to debug per the description... We fixed a bug where apps could create several tokens earlier this year, I guess you still experiencing the issue now?

We've just been banned for another 24 hours during the session refresh. Our web platform has a high connection traffic (we can easily reach 10,000 failed connections in 10 minutes), which penalizes us heavily and prevents our users from connecting. We have had to temporarily disable the OAuth2 connection to Discord and invite disconnected members to connect using another connection method, which prevents them from accessing their preferences and data. Doesn't Discord have a monitoring mechanism? These errors should have been detected much earlier by the team.