Google OAuth code

During a penetration test on my site (Open-EDX courses site), it was found that the OAuth code can be reused to obtain multiple active session tokens (checked on google OAuth).
Thus, an attacker who has obtained a victim’s code might use it to generate a valid
session token and take over the victim’s account.
Does Open-EDX contain any feature that can Invalidate the OAuth code after the first use?

If you believe this represents a security vulnerability, please report the details to security@edx.org instead of this forum. Only reply to this thread if you don’t think there’s an actual vulnerability here.

Are you talking about using a Google Account to log in to an Open edX instance? And about the “authorization code”, which Open edX exchanges with the Google Auth servers to get back an access token and a refresh token? (this step). If so, it is Google’s responsibility to ensure the code cannot be used more than once, per the OAuth2 spec 4.1.2:

If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. The authorization code is bound to the client identifier and redirection URI.

As I understand it, if you genuinely found a way that the authorization code can be re-used, you should report that to Google.

Or maybe you are talking about the auth flow that the mobile app uses (“auth exchange”)? If so, please discuss your findings with the security team using the email above; I’m not sure of the details of that flow.

Or if you are talking about Open edX as an OAuth provider, and somehow using Google as a client to test Open edX as an identity provider where Open edX issues an auth token to google which google exchanges for a refresh token, that would probably represent a vulnerability in Open edX which you should report to that email address, but I’m not familiar with any way to use “Google OAuth” in that way.

On the other hand, if by “code” you actually are referring to the “refresh token” or “access token”, they are both bearer tokens which necessarily can be re-used multiple times. Some systems cycle the refresh tokens every time they are exchanged for an access token, which improves security, though I don’t know if the Open edX OAuth implementation does that or can does that. It’s probably possible if you’re interested, but the lack of that feature wouldn’t count as a vulnerability since it’s fairly typical.