Uploaded image for project: 'PUBLIC - OAuth2'
  1. PUBLIC - OAuth2
  2. OAUTH2-42 REQ029 Authorization Code Flow: Prevent Impersonation of Resource Owner
  3. OAUTH2-96

REQ029.UC001 PREVENT Misuse of Authorization Code to Impersonate Resource Owner


    • Type: Sub-Task
    • Status: Closed
    • Priority: Minor
    • Resolution: Completed
    • Affects Version/s: None
    • Fix Version/s: 1.0-portal_7.1.0
    • Component/s: None
    • Labels:



      Undesirable postconditions:

      • Legitimate application user account is victim’s
      • OAuth2 service user account is attacker’s
      • Attacker can log into the victim’s legitimate application user account at any time (until victim disconnects the OAuth2 service on the application side)


      Due to the stateless nature of the web, there is not safe to assume that the authorization code is sent to the legitimate app as a consequence of authorization server interactions with the legitimate user.



      • The legitimate app retrieves user information from the OAuth secured API and matches it with a local account in the target app’s database to log them into the target app
      • The legitimate app allows its users to log in with or link their account to multiple OAuth providers
      • The victim has previously registered as a user with the OAuth provider
      • The victim is logged in at the OAuth provider
      • The attacker registers as a user with the same OAuth provider


      Event flow:

      1. The attacker initiates a login to the legitimate app, but uses a browser plugin or similar to prevent the browser following the redirect back to the legitimate app at its redirect_uri after authenticating and granting authorization at the OAuth2 provider
      2. The victim is tricked into visiting the URL from the attacker’s redirect
      3. Visiting the URL will trigger an exchange of authorization code for access token and the legitimate app will then link the access code to the victim’s user on the legitimate site
      4. Since the victim’s user at the legitimate app is now linked to the attacker’s user at the OAuth provider and the attacker can log in as the victim at any time


      Expected outcome: The OAuth provider should not provide the access token


      Mitigation @ Legitimate client:

      • This is essentially a CSRF attack on the redirect_uri, so a CSRF token MUST be provided when exchanging the authorization code for the access token. The OAuth2 spec provides the “state” parameter which should be provided by the legitimate when requesting authorization. The OAuth provider MUST reflect the same parameter when sending the request to the redirect_uri, enabling the legitimate app to check the CSRF token.


      Mitigation @ OAuth2 Provider


          Issue Links



              tomas.polesovsky Tomáš Polešovský
              Participants of an Issue:
              0 Vote for this issue
              0 Start watching this issue




                  Version Package