OAuth and OpenID Connect (OIDC) Configuration Vulnerabilities: Real-Life Attack Scenarios

Today, we will talk about the vulnerabilities that arise from the incorrect and weak configuration of widely used protocols. Technologies like OAuth and OpenID Connect make our web applications more secure and user-friendly, but if you make a mistake, hackers are waiting at the door!

What is OAuth?

OAuth addresses a common situation we encounter in modern web applications: "An application asks you to log in using your Facebook or Google account." This is where OAuth comes in, offering a secure method to grant access with your permission.

Let's say you see the "Log in with Facebook" option when logging into an application. When you select this option, the application redirects you to Facebook. However, the application never sees or saves your username and password. Instead, it uses the OAuth protocol to request access and, with your permission, accesses specific data (like profile, email). In this way, the application provides a secure login process by directly associating you with the authentication provider.

This is exactly an OAuth model. In short, OAuth grants limited access to third-party applications, but not for fully authenticating your identity – that part is left to OIDC. The image below might help you understand better.

In short, we call such structures OAuth. The structure on the backend is as follows: First, a request is made to the service we are using for OAuth (e.g., Gmail) containing the client_id and the URL of the respective application.

Example Request:

GET https://accounts.google.com/o/oauth2/v2/auth?client_id=your_client_id&redirect_uri=https://yourapp.com/callback&scope=profile email&response_type=code&state=random_state_value

If everything goes well and the user gives permission, the Gmail service makes a new request to create a token.

Token Request:

POST https://www.googleapis.com/oauth2/v4/token
Content-Type: application/x-www-form-urlencoded

code=received_auth_code&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=https://yourapp.com/callback&
grant_type=authorization_code

When completed successfully, the API returns a token to the user:

{
 "access_token": "ya29.a0AfH6SMC...example_token",
 "expires_in": 3600,
 "token_type": "Bearer"
}

Thus, an OAuth cycle is completed.

What is OpenID Connect?

OpenID Connect is somewhat similar to OAuth in its explanation. Therefore, to avoid confusion, let me give a warning right at the beginning: OAuth provides an access token (to access data), while OIDC authenticates your identity by adding an ID token.

In other words, OpenID Connect performs the process of authentication and providing information about the user's identity based on the OAuth protocol.

When you want to log in to an application with OpenID Connect, the application redirects you to an identity provider (e.g., Google, Facebook). The identity provider verifies your credentials and gives you an ID Token, which is an identity certificate. This ID Token is sent back to the application, and the application uses this token to verify your identity.

For example, when you select the "Log in with your Google account" option, OpenID Connect comes into play. It redirects you to the identity provider, verifies your credentials, and provides an ID Token. The application uses this token to log in.

OAuth vs. OIDC Comparison

OAuth and OpenID Connect Vulnerabilities

If you are not familiar with these technologies and standard web communication, it might seem very complicated. Before you kick your computer, you can do some research from different sources (for example, OWASP guides).

Now that we have some understanding of OAuth and OpenID Connect, we can examine the vulnerabilities that arise from them. In this part of the topic, I will explain using real-life scenarios reported on platforms like HackerOne to give you more realistic scenarios.

JWT (Json Web Token) Attacks

JSON Web Token (JWT) is an authentication mechanism used in the OpenID Connect protocol. It is an architecture that makes life easier for many developers, including myself. However, if not configured correctly, it can lead to many vulnerabilities such as Account Takeover, Token Overflow, and the 'none' algorithm vulnerability. Attack vectors vary depending on the target site's architecture.

Account Takeover Example

For example, in a structure that uses JWT, a JWT parameter is present in every request when logging into the website (usually in the Cookie or Header).

JWTs are not always stored in cookies, but you can automatically detect them with tools like Burp Suite.

When we decode the JWT in the cookie, it looks like this:

As you can see, the user information only contains my nickname. It is not protected with any other key. However, in any case, I need the Secret Key for the JWT.

To obtain this, you can use tools like John The Ripper or Hashcat.

echo "jwttokeniniz" > jwt.txt
./john jwt.txt --format=HMAC-SHA256 --wordlist=wordlist/dizini/rockyou.txt

As you can see in the image, the Secret Key turned out to be "ilovepico". Now we can change the data inside the JWT and re-sign it (for example, change the user to "admin").

As you can see in the image above, I changed the user to 'admin' and entered the secret key we cracked into the VERIFY SIGNATURE field. On the bottom left, it indicated that our JWT was approved with 'Signature Verified'. Now, let's copy our manipulated JWT code, change it on our server, and see what happens.

I am changing my JWT in Burp Suite.

As you can see in the image above, we have logged in as admin.

'None' Algorithm Vulnerability

This vulnerability is a critical configuration error that has the potential to completely disable JWT signature verification. The JWT standard allows the value 'none' in the alg (algorithm) header to specify unsigned tokens. If the server-side library or code is incorrectly configured to accept this value as a signature algorithm, attackers can remove the signature part and manipulate the token as they wish.

Example Attack Steps:

1.Capture the Original Token: The attacker captures a valid JWT from the application.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoidXNlcjEyMyJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

2.Decode the Token: Decode the header and payload parts of the token from Base64 format.

Header: {"alg": "HS256", "typ": "JWT"}

Payload: {"user": "user123"}

3.Manipulate the Token: Change the alg value in the header to 'none' and the user in the payload to 'admin'.

Yeni Header: {"alg": "none", "typ": "JWT"}

Yeni Payload: {"user": "admin"}

4.Create the New Token: Re-encode the modified header and payload with Base64 and leave the signature part empty. The period character at the end of the token must remain..

Attack Token: eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4ifQ.

5.Send the Request: When the attacker sends a request to the server with this manipulated token, the misconfigured server accepts the information in the payload as valid without any signature verification and grants the attacker access with admin privileges.

This vulnerability is particularly common in older libraries (e.g., some Node.js JWT libraries) and is classified as high-risk by OWASP.

Another topic to look at is Exploit Chaining, which means vulnerability escalation or combining different vulnerabilities. Exploit Chaining means using one vulnerability to jump to another, multiplying the impact in real attacks.

A scenario I experienced in a bug bounty program: Couldn't crack the password? Scan for exposed directories (for example, the .env file). In my example, an .env file was left exposed on a site and it contained the JWT_SECRET.

This way, we get the secret without the hassle of decoding. Extra tip: also check for .git and backup files. This chaining enhances the impact by combining one vulnerability (directory enumeration) with another (JWT cracking).

Another example for exploit chaining could be this:

Let's say an Open Redirect vulnerability was first found on a site (redirect URI manipulation). By using this to redirect the user to a phishing page, the JWT token can be stolen there (for example, with XSS). Then the stolen token can be decoded, manipulated with the 'none' algorithm, and the admin account can be taken over. Or, after getting the secret from .env, it can be combined with IDOR (Insecure Direct Object Reference): access to other users' data can be gained with the manipulated JWT. This chain makes low-level vulnerabilities critical.

Lack of State Parameter (CSRF Attacks): In the OAuth flow, the 'state' parameter prevents CSRF. If it's missing, an attacker can redirect the user to a fake login page and steal the token. For example: a fake link can be sent to the user via email, and if the state is not validated, access is granted.

Unchecked Callback Structures

OAuth structures say "Yes, the process is complete, grant authorization" via a callback.

However, if the callback made here is not checked, malicious attackers can come and say to the service; "I have completed this process, you can now allow person X to log in as admin."

I will base this explanation on a report I found on HackerOne. If you want to read it, you can do so from this address.

The user follows this OAuth structure at login:

redirect_uri=https%3A%2F%2Fbooth.pm%2Fusers%2Fauth%2Fpixiv%2Fcallback&response_type=code&scope=read-works+read-favorite-users+read-friends+read-profile+read-email+write-profile&state=%3A1a38b53563599621ce25094661b1c4458ddb52d79d771149

The attacker performs path traversal by changing the redirect_uri:

redirect_uri=https%3A%2F%2Fbooth.pm%2Fusers%2Fauth%2Fpixiv%2Fcallback/../../../../ja/items/4503924​

Thus, since there is no mechanism in the service that checks the callback response, they log into the account of the user with ID 4503924.

Again, in a different HackerOne report, a user exploits an open redirect vulnerability by modifying the URL to which the callback in OAuth redirects. This situation creates strong phishing scenarios targeting the company's users.

So, in fact, when we look at the examples, the failure to properly check the redirect_uri parameter by the server opens the door to many critical vulnerabilities such as Open Redirect, Path Traversal, CSRF, and Account Takeover.