These days, more and more companies use single sign-on or SSO to manage access to their services and applications. This way, they delegate the authentication or authorization process to a trusted third party, allowing users to sign in to different services with the same access data.

It’s true that SSO rescues users from the hassle of remembering login credentials or access data for each service. However, this method is prone to security gaps. If these gaps are not identified in time, an organization can be exposed to grave consequences. These situations can worsen to a point where the confidentiality and integrity of critical data are at the stake. Needless to say, all this can hit a company’s finances, reputation, and operations.

This blog intends to help new penetration testers and companies understand why SSO can be risky and what common vulnerabilities to look out for.

What Makes SSO Vulnerable?

The primary reason SSO is more prone to security issues is that the developers lack a deep understanding of OAuth, Open ID Connect, or SAML technologies. Thus, when they generate complex standards for these technologies, security loopholes are almost inevitable.

That’s exactly why most developers use ready-made or off-the-shelf SSO solutions. Such solutions already have all the primary functionalities built in them. However, these ready-made SSO solutions also have many security flaws, which can be exposed in a penetration test.

Usually, companies configure these solutions in a basic way. They skip the extra security features because everything seems to work fine even without them. However, the reality is that these ignored features are the exact backdoors that allow attackers in.

Common SSO Vulnerabilities Found in Penetration Tests

Here are the SSO vulnerabilities that have prevailed lately-

1.    Insufficiently Validated Redirect URI

Whenever a user logs into an application through OAuth and OpenID Connect, they are directed to an identity provider or authorization server via an Authorization/ Authentication (AuthN) request. This is where the actual login process is carried out.

This AuthN includes a redirect URI, which is basically a link to an endpoint where the user is redirected after the login. Since sensitive OAuth parameters are transmitted to the redirect URI, security issues arise when it isn’t properly secured or strictly validated. Based on the chosen OAuth flow, the identity provider develops an OAuth 2.0 code or an access token that is sent to the redirect URI link.

But how exactly can this vulnerability be exploited?

Well, if an attacker gets another user’s code, they can exchange it for an access token with the identity provider or authenticate themselves to the application as the other user. If additional protection mechanisms like PKCE are not used, attempting this type of authorization code injection attack becomes easier.

How Does a Professional Pen Tester Detect Insufficiently Validated Redirect URI?

Let’s break down this process in 5 simple steps-

1. Reconnaissance and Auth Flow Mapping

The pen tester first analyzes the SSO authentication flow—usually via tools like Burp Suite or ZAP—and captures the Authorization/Authentication request. Then, they identify the redirect_uri parameter used in OAuth/OpenID Connect login requests.

2. Modification

Next, the penetration tester tampers with the redirect URI by replacing the legitimate value with a malicious domain specifically created for simulating such attacks.

3. Observing the Behaviour

They complete the login flow (or can even trick a test user into doing so) and check if the identity provider allows redirection to the modified URI after a successful login. They also check if any OAuth tokens, codes, or session identifiers are passed to the malicious redirect.

4. Checking for Validation Bypass Techniques

If strict validation is in place, they try alternative bypassing techniques, such as using subdomains, encoded characters, path traversal, or appending additional query parameters.

5. Confirming the Vulnerability

If the identity provider does not validate the redirect URI properly and sends sensitive tokens to the attacker-controlled endpoint, the vulnerability is confirmed.

Generic Remediation

Configure the identity provider to allow redirects only to pre-registered, exact redirect URIs. Avoid using wildcards (e.g., *‘example.com`) in redirect URI configurations, as they can be exploited to redirect sensitive tokens to attacker-controlled domains. Strict URI validation should be enforced to prevent unauthorized redirection.

2.    Missing PKCE Protection Mechanism for Public Clients

PKCE stands for Proof Key for Code Exchange— a security layer that is used in OAuth and Open ID Connect. PKCE prevents authorization code injection attacks by creating a link between the AuthN request and the redemption of codes in the token request.

If there is no PKCE, threat actors can easily redeem a code via a token request in a public client. This allows them to exchange a stolen token for the compromised user.

This is possible because a public client (like a mobile or browser-based app) does not use a client secret. Because of this, if an attacker somehow gets access to another user’s authorization code, they can directly exchange it for an access token without needing any extra secret.

This stolen code can come from many sources, like:

• Badly set up referrer policies.
• XSS (cross-site scripting) attacks.
• Vulnerable redirect URIs.

If that code belongs to an admin, then the attacker can gain full access to all admin-level data and actions.

How Does a Professional Pen Tester Detect if There is a Missing PKCE Protection Mechanism for Public Clients?

Here are the steps a white-hat hacker will generally follow-

1. Starting with a Valid Login Flow

A penetration testing expert uses a proxy tool like Burp Suite to intercept the AuthN request. It then observes if the request contains code_challenge or code_challenge_method.

If these are missing, then the app might not be using PKCE.

2. Check the Client Type

They confirm that the app is a public client by seeing if no client_secret is used. They often use browser-based SPA and mobile apps for this. Lastly, they go through OAuth settings and documentation, if available.

3. Extract the Authorization Code

Next, they complete a normal login and capture the code parameter from the redirect URL.

4. Manually Replay a Token Request (Without PKCE)

They send the following POST request to the token endpoint-

POST /token HTTP/1.1

Host: idp.example.com

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&

code=abc123&

redirect_uri=https://yourapp.com/redirect&

client_id=public-client-id

If the server responds with an access token, it confirms that PKCE is not enforced.

5. Simulate Code Injection Scenarios

Then, they repeat the above steps using stolen or replayed code from another test user account. If the app allows a resume but doesn’t validate PKCE, it has a serious flaw.

6. Confirm the Vulnerability

The vulnerability is confirmed if the penetration observes the following-

• The authorization request has no code_challenge.
• The token endpoint allows redemption of the code without a code_verifier.
• No client secret is required (common for public clients).

Generic Remediation

Enforce PKCE for all public clients, especially browser-based SPAs and mobile apps. Ensure that the AuthN request includes a code_challenge and code_challenge_method=S256, and the token request includes the correct code_verifier. The authorization server must validate that the hash of the code_verifier matches the original code_challenge before issuing tokens. This helps prevent attackers from exchanging stolen authorization codes.

Are you noticing your competitors putting out regular blogs while you’re still figuring it out? No stress—I can help with that. If you’d like to build something similar (or better) for your site, just drop me a message at daksh@turtlewords.com. Let’s discuss what we can create together.