OAuth Basics: What It Is and Why It Matters

OAuth is a framework for delegated access that lets third-party apps act on a user behalf without sharing passwords OAuth 1.0 used signatures, while OAuth 2.0 simplifies the flow by relying on TLS and bearer tokens

OAuth 2.0 specifically allows login to a site (Client App) using an external provider like [ Google ,Apple ,Facebook ] (Authorization Server) without entering an email or password on the Client App It’s all about token exchange in the background

Key components:

• 1 Authorization Server: The provider (e.g., Google) that authenticates the user and issues tokens
• 2 Client App: The target site you’re logging into via OAuth.
• 3 Authorization Code: A one-time code from the Authorization Server exchanged for an Access Token
• 4 Access Token: Grants access to protected resources often refreshed with a Refresh Token
• 5 Resource Server: Hosts the user’s data (e.g., Google’s API server).

The flow is redirects from client side to server side and exchanges Here’s the high-level ASCII

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

Steps in background :

1User (you) initiates login on Client App via OAuth

2Client App redirects to Authorization Server (e.g., https://accounts.google.com/o/oauth2/v2/auth?client_id=...&redirect_uri=...&scope=...&response_type=code)

3Authorization Server authenticates user (if not logged in) and prompts for consent

4User grants access; Authorization Server redirects back to Client App’s redirect_uri with code parameter (e.g., https://client-app.com/callback?code=AUTH_CODE)

5Client App exchanges code for Access Token via backend request to Authorization Server (e.g., POST to /token endpoint with client_secret)

6 With Access Token Client App fetches user data from Resource Server and logs you in

NOTE: From a pentester OR Bug hunter view this flow is ripe for abuse because the code is a golden ticket if leaked it’s often exchangeable for a session leading to ATO Misconfigurations amplify this as seen in bug bounties where OAuth flaws yield high payouts

Where The Secrets !!!!!

The Secret in This Parameters:

First Scenario CSRF

1 &state=

. The parameter which can be set in the first step can either be a cookie or stored in local storage

He Authorization Server After Multiple Redirects Checks Whether The state Token Sent In The First Step Is The Same In The Third Step

if We Send The same token in the state parameter to the victim The Attack Won’t Work Because The Authorization Server Verifies The state

But wait many applications dont require the state parameter which allows the attack to succeed if the Authorization Server doesn’t verify it This Can Lead To CSRF

Lets move on to the second scenario Open Redirect

2 &Redirect_uri=

. redirect_uri parameter is crucial — it is the primary vector for many redirect-based attacks

. In the second request the Authorization Server receives The redirect_uri parameter Which Specifies The URL To Thich The Server Will Redirect The User Along With The Authorization Code

In this Scenario An Attacker Configures Their Server As The redirect_uri When The Victim is Redirected There The Attacker Receives The Authorization Code The Attacker Can Then Exchange The Code For An access/session Token And Use it To Take Over The Victim Account (ATO)

Unfortunately this attack is unlikely to succeed in modern applications because authorization servers typically validate the redirect_uri against a whitelist Therefore an attacker must use an alternative technique commonly exploiting an open redirect or another vector to exfiltrate the authorization code

BYPASS Open Redirect :

1 Start with/indexOF: target.com.Attacker.com
2 Fake Relatev : //attacker.com
3 /\? before the @: https://attacker.com\@target.com , https://[email protected]
4 Multililne regex: attacker.com%0d%0atarget.com
5 Parameter Pollution : redirect=https://target.com&redirect=https://attacker.com

Account Takeover(ATO) #1🔥

3 &Response_Mode=

. can Be Used To Change With Other Attacks

. The Normal Value of Parameter is : query

Another Possible Value for the response is : fragment

The code here shows up in the URL fragment instead of the query Since the callback only reads the query it ignores the fragment leaving the code exposed but unused

If the code is placed in the URL fragment the callback endpoint will most likely not consume it and we`ve seen it exploited for example in reddit where Frans Rosen

would change this parameter and then the code would be just present in the url unconsumend which is very important and then you need another back to leak the url which is not easy to get but here it was really great back i think xss we also but if you have Other bug can leak the url you can takeover

CSRF + Open Redirect Lead To ATO #3

. This Scenario is Two Bugs Lead To ATO Easy

. First I Found Open Redirect in POST Auth CSRF State

After Me SuccessFully Log in The Code Send To The Attacker Domain So i did was i Changed The Response mode to Fragment and in the Redirect URI I embedded my Code From my Web From my Account To The Target Website So the authorzation server would redirect the victim into this url with my code in the query with the state

That Redirects to my website and then the authorzation server because we used response mode fragment

would add victim code and other parameters in the fragment so then the victim would be successfully logged in my account because was my code

After the victim is redirected post authentication to the attacker URL (in this case, the attacker account) the authorization code remains in the URL fragment Because the fragment persists across the redirect the attacker can exfiltrate the code and exchange it for an access/session token resulting in an account takeover (ATO)

All This Bugs Severity is : Critical

……………Thank You For Reading And I hope This Was helpful………………