Security in OAuth2 : protecting against authorization code attack

If you recall authorization code flow, an authorization code represents an authorization grant from the user that’s sent by the Authorization Server in the front channel. Unfortunately, Authorization Server isn’t mandated to maintain a state between the user and the authorization code. This may lead to an attack where an authorization code for Bob may be replaced by Alice’s and Alice may hijack Bob’s session assuming it is the same OAuth client used by both users. In this article let us learn how PCKE solves this.

🚀 Preparing for FAANG or Top Startup Interviews?

Watching hours of tutorials but still freezing in interviews?

FAANG doesn’t test memory — it tests structured thinking and real problem-solving patterns.

**Educative helps you practice actual questions from Google, Meta & Amazon, plus recruiter-relevant projects. 👉 [See how top candidates prepare](https://www.educative.io/unlimited?aff=xkRD)**

What’s authorization grant flow?

Please refer to my article on authorization grant flow to understand the finer details.

Why is authorization grant flow susceptible to authorization code attack?

To clarify OAuth2.1 mandates PCKE so this attack is not feasible in its current form but let us still try to understand the attack and then we can realize how PCKE helps. Use the slider below to understand how Bob’s authorization code may be replaced by Alice.

+------------+       +---------+       +-------------------+       +----------+
|    User    |       |  Client |       | Authorization     |       | Attacker |
|   (Bob)    |<----->|         |<----->|      Server       |<----->|  (Alice) |
+------------+       +---------+       +-------------------+       +----------+
      |                   |                       |                       |
      | 1. Request Login  |                       |                       |
      |------------------>|                       |                       |
      |                   |                       |                       |
      | 2. Redirect to    |                       |                       |
      |    Auth Server    |                       |                       |
      |<------------------|                       |                       |
      |                   |                       |                       |
      | 3. Authenticate & |                       |                       |
      |    Authorize Bob  |                       |                       |
      |------------------------------------------>|                       |
      |                   |                       |                       |
      | 4. Issue Bob's    |                       |                       |
      |    Auth Code      |                       |                       |
      |<------------------------------------------|                       |
      | (Auth Code for Bob)                       |                       |
      |                   |                       |                       |
      |                   |                       |                       |
      |               (Attacker's Pre-obtained Auth Code for Alice)      |
      |                                                                  |<----------|
      |                                                                  | 5. Obtain |
      |                                                                  |    Auth   |
      |                                                                  |    Code   |
      |                                                                  |  (Alice)  |
      |                   |                       |                       |---------->|
      |                   |                       |                       |
      |                   |                       |                       |
      |                   |   6. Attacker         |                       |
      |                   |      Intercepts &     |                       |
      |                   |      Replaces Code    |                       |
      |                   |----------------------------------------------------->|
      |                   | (Bob's Code is replaced by Alice's Code)           |
      |                   |                                            |
      |                   | 7. Redirect with      |                       |
      |                   |    Alice's Auth Code  |                       |
      |<------------------------------------------|                       |
      |                   |                       |                       |
      |                   |                       |                       |
      |                   | 8. Exchange Code      |                       |
      |                   |    (Alice's Code)     |                       |
      |                   |---------------------->|                       |
      |                   |                       |                       |
      |                   | 9. Issue Tokens       |                       |
      |                   |    (for Alice)        |                       |
      |<------------------|-----------------------|                       |
      |                   |                       |                       |
      | Session Hijacked: |                       |                       |
      | Bob's browser now |                       |                       |
      | has Alice's       |                       |                       |
      | session/tokens    |                       |                       |
      +-------------------+-----------------------+-------------------+-------------------+

As you can see, this attack requires the same client to be used in this flow since an authorization code should be tied to a particular client_id that started the OAuth flow.

How does PKCE stop this attack?

While using PKCE in the flow, the client generates a random value, which becomes the code_verifier. It then transforms this code_verifier into a code_challenge (e.g., by hashing it). At the start of the OAuth 2.1 flow, the client sends the following two parameters:

• code_challenge: The transformed (e.g., hashed) value of the random secret.
• code_challenge_method: The transformation (hashing) algorithm used (e.g., S256).

At the Authorization Server side, it remembers the code_challenge and the code_challenge_method received in the initial authorization request (as they are part of the URI). However, in the backchannel flow, after the authorization code is received by the client and then posted by the client to the Authorization Server's token endpoint, the client also sends the cleartext code_verifier so that the AS can match the cleartext value with the hashed value it previously stored. This allows binding a particular user-agent/client with the given authorization code, preventing Alice from swapping codes.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: **X | [Medium](https://medium.com/codetodeploy)**

👉 CodeToDeploy Tech Community is live on Discord — **Join now!**

👉 Follow our publication, CodeToDeploy

Note: This Post may contain affiliate links.