If you are from an IT company, your tech infrastructure is most likely to have OAuth 2.0 and OpenID Connect (OIDC) as its core components. Together, these protocols allow a secure and seamless user authentication across applications. OAuth 2.0 is deployed to enable users to access third-party applications without needing to enter passwords, while OIDC is built on top of OAuth 2.0 to verify that the user is indeed who they claim to be.

However, despite their ease and accessibility, these protocols remain among the most vulnerable components of the attack surface. This is primarily because of their complex configurations, which are often not set up correctly, leaving exploitable security gaps.

However, if a seasoned penetration tester enters the scenario, they can simulate an attack on these protocols to identify flaws and walk through real-world exploitation scenarios. This way, you can identify and remediate misconfigurations, thereby closing gateways to potential attacks.

Here is a detailed blog on the vulnerabilities detected during a penetration test of OAuth 2.0 and OIDC.

What is OAuth 2.0 and Why do Threat Actors Exploit it?

It’s common for cybercriminals to misuse OAuth applications as an automated tool, especially in attacks intended to achieve financial gains. OAuth 2.0 is an open standard that involves token-based authentication and authorization so that applications get access to data and resources based on permissions set by a user.

Threat actors hack into user accounts and then create or modify OAuth apps with high-level permissions (for example, granting full access to sensitive files, allowing hackers to read or modify user profiles, permitting creation and management of virtual machines, etc.). These apps help them stay hidden and maintain access, even if the original account is secured later. Once inside, they used OAuth apps to mine cryptocurrency, send spam, and remain active after business email compromise (BEC) attacks, among other malicious activities.

In fact, recently, Microsoft Threat Intelligence Center detected an active and successful device code phishing campaign launched by Storm-2372, a threat actor group. The attackers leveraged the OAuth 2.0 Device Authorization Grant flow to generate a legitimate device code, which later evolved into a sophisticated phishing campaign.

This is just one of the many cyberattacks emerging from OAuth exploitation. Such incidents underscore the importance of regular penetration tests, which can help identify and correct misconfigurations before they are exploited, thereby mitigating potential security risks.

What is OIDC and Why do Threat Actors Exploit it?

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It allows apps to verify a user’s identity by using an identity provider like Google, Microsoft, or Facebook. When you click “Sign in with Google,” OIDC is what’s making that magic happen—passing a secure ID token to the app that says, “Yes, this is the user they claim to be.”

Since OIDC has weak token validation, developers may skip key checks, such as verifying the aud (audience) or iss (issuer) claims in ID tokens, and malicious actors can exploit this as an ideal loophole.

Common Security Pitfalls and How Penetration Testers Identify Them

Here are the common misconfigurations and security loopholes in OAuth 2.0 and OIDC, and how a professional pen tester can test them.

Wildcard Redirect URIs

• The issue: Apps that allow redirect URIs like https://example.com/* open the door for attackers to supply malicious subpaths—e.g., https://example.com/evil. This can let attackers intercept authorization codes or tokens.
• How a pen test detects it: A tester tries to register OAuth apps or initiate flows using crafted redirect URIs that still pass validation, observing whether the app accepts unexpected paths.

Open Redirects in OAuth Flow

• The issue: Open redirect endpoints in the app (e.g., /redirect?url=https://attacker.com) can be abused in the OAuth redirect URI. This allows attackers to steal authentication codes or tokens by redirecting the user from a trusted domain to a malicious one.
• How a pen test detects it: The tester locates redirect endpoints and embeds them in OAuth flows, confirming whether tokens or codes are passed along to attacker-controlled domains.

Loose Redirect URI Matching

• The issue: When apps match only a prefix or allow partial matching in redirect URIs, attackers can manipulate subdomains or query strings to hijack the flow (e.g., https://trusted.com.attacker.com).
• How a pen test detects it: Testers enumerate all variations of the redirect URI and attempt OAuth requests with subtly altered values to check for unauthorized acceptance.

Lack of HTTPS Enforcement

• The issue: If OAuth endpoints or redirect URIs accept http:// instead of strictly requiring https://, data in transit (like tokens or codes) can be intercepted via MITM attacks.
• How a pen test detects it: A penetration tester initiates flows or exchanges tokens over HTTP and inspects for successful transactions or token leakage.

CSRF in OAuth Endpoints

• The issue: If OAuth endpoints fail to validate the state parameter properly, attackers can trick users into authorizing unintended actions, resulting in cross-site request forgery (CSRF)- style attacks during the OAuth handshake.
• How a pen test detects it: The tester initiates an OAuth request without or with a mismatched state and checks whether the app processes the response, indicating that it lacks CSRF protection.

Final Words

As OAuth and OpenID Connect continue to evolve, so do the ways they can be broken. Their growing complexity means security can’t be a one-time setup—it demands constant vigilance.

For penetration testers, these protocols are a goldmine of misconfigurations and real-world exploit potential. For developers and security teams, they’re a high-stakes puzzle that needs an airtight implementation and regular testing.

In this cat-and-mouse game, staying sharp isn’t optional—it’s essential. Whether you’re breaking or building, the goal is the same: stronger, smarter authentication for everyone.

If you also want to cover intricate technical topics in your blog but lack the right resources to do so, I might be the perfect choice. I am Daksh Kaur, a freelance cybersecurity writer with over five years of experience in the industry.

What do I bring to the table— bite-sized explanations of complex topics that answer the questions of your target audience and educate them to try your products and services to shield their businesses. My content doesn’t just educate; it also drives sales.

So, send me a ‘Hi’ at daksh@turtlewords.com, and let’s talk about how we can collaborate.