OIDC Exploitation: Cyber Attacks Exploiting Vulnerabilities in the OpenID Connect Protocol!

To comprehend OIDC exploitation, one must first grasp the core additions OIDC makes to the standard OAuth 2.0 flow.

The primary innovation of OIDC is the ID Token. While OAuth 2.0 provides an Access Token (which is opaque to the client and intended only for the Resource Server), OIDC explicitly designed the ID Token to be consumed by the Client application itself. The ID Token is formatted as a JSON Web Token (JWT). It contains specific "claims" (key-value pairs) about the authenticated user and the authentication event itself.

Critical claims within an OIDC ID Token include:

• iss (Issuer): The URL of the Identity Provider that issued the token (e.g., https://accounts.google.com).
• sub (Subject): A unique identifier for the user within the context of the Issuer.
• aud (Audience): The client_id of the application the token was explicitly intended for.
• exp (Expiration Time): The timestamp after which the token must not be accepted.
• iat (Issued At): The timestamp when the token was issued.
• nonce (Number used once): A string value used to associate a Client session with an ID Token, preventing replay attacks.

Another crucial OIDC concept is the Discovery Endpoint (typically located at /.well-known/openid-configuration). This endpoint provides a JSON document detailing the IdP's configuration, including supported scopes, supported response types, and crucially, the URL of the JSON Web Key Set (JWKS), which contains the public keys required to verify the digital signatures of the ID Tokens.

The OIDC flow heavily relies on the Client application properly receiving, parsing, and, most importantly, cryptographically validating the ID Token. If the Client fails to perform rigorous validation on any of these claims or the digital signature, the entire authentication mechanism collapses.

Because the ID Token is a JWT, the most prevalent OIDC vulnerabilities stem directly from flawed JWT handling libraries or improper implementation of JWT validation logic within the Client application.

The alg: None Attack

This is a classic, critical vulnerability that still occasionally surfaces in legacy systems or custom JWT implementations. A JWT consists of three parts: Header, Payload, and Signature. The Header specifies the cryptographic algorithm used to sign the token (e.g., alg: RS256).

In the alg: None attack, an adversary takes a valid ID Token, modifies the Payload to elevate their privileges or impersonate another user (e.g., changing the sub or email claim), and then modifies the Header to specify alg: None. They then remove the Signature entirely. If the Client application's JWT library is misconfigured to trust the algorithm specified in the Header without enforcing a secure baseline, it will accept the "unsigned" token as valid. The attacker achieves a complete authentication bypass.

Signature Confusion Attacks (RS256 vs HS256)

This vulnerability arises when an application expects an asymmetric signature (e.g., RS256, where the IdP signs with a private key and the Client verifies with a public key) but fails to enforce this expectation.

In a Signature Confusion attack, the adversary downloads the IdP's public key (which is intentionally public via the JWKS endpoint). The attacker then modifies the ID Token payload to impersonate a victim. Crucially, the attacker changes the Header's algorithm from RS256 to HS256 (a symmetric algorithm requiring a shared secret). The attacker then signs the modified token using the IdP's public key as the symmetric secret.

When the vulnerable Client application receives this token, it sees HS256 in the header. It looks up the key it normally uses for verification (which it believes is the IdP's public key). Because the application thinks it's doing an HS256 verification, it uses the public key as the symmetric secret to verify the signature. Since the attacker signed the token using that exact same public key as the secret, the verification succeeds, leading to a critical compromise.

JWK Injection and Key Confusion

OIDC requires Clients to verify the ID Token signature using keys retrieved from the IdP's JWKS endpoint. Sometimes, the JWT Header includes a jku (JWK Set URL) or jwk (JSON Web Key) parameter, directing the Client to the key that should be used for verification.

If the Client application blindly trusts the jku parameter without validating that it points to the legitimate IdP's domain, an attacker can host their own malicious JWKS endpoint. The attacker creates a forged ID Token, signs it with their own private key, and sets the jku header to point to their malicious server. The vulnerable Client downloads the attacker's public key, verifies the forged token successfully, and grants the attacker access.

Beyond JWT-specific issues, vulnerabilities often arise from how developers implement the broader OIDC protocol requirements.

Ignoring the nonce Parameter

The nonce parameter is critical for preventing replay attacks, especially in flows where the ID Token is returned directly from the authorization endpoint (like the Implicit flow or Hybrid flows).

When initiating the OIDC flow, the Client must generate a unique, cryptographically random nonce, store it in the user's session, and send it in the authorization request. The IdP includes this exact nonce in the resulting ID Token. The Client must then verify that the nonce in the token matches the one stored in the session.

If the Client fails to implement or validate the nonce, an attacker who intercepts a valid ID Token (e.g., via a compromised network or malicious browser extension) can reuse that same token repeatedly to authenticate as the victim, even long after the original authentication session has ended, provided the token hasn't expired.

Failing to Validate the aud and iss Claims

An ID Token is issued by a specific Issuer (iss) for a specific Audience (aud - the Client application).

If a Client application fails to validate the aud claim, it becomes vulnerable to token substitution. Suppose an attacker creates a malicious application (App A) that also uses the same IdP (e.g., Google). The attacker tricks the victim into logging into App A, obtaining a valid ID Token for the victim. The attacker then takes this token and presents it to the target application (App B). If App B only checks the signature (which is valid, as Google signed it) but ignores the aud claim, it will log the attacker in as the victim.

Similarly, failing to validate the iss claim allows an attacker to set up a rogue Identity Provider. If the target application expects tokens from accounts.google.com but doesn't explicitly check the iss claim, it might accept a mathematically valid token signed by evil-idp.com, leading to account takeover.

The complexity of OIDC and JWTs has led to numerous high-profile vulnerabilities in major platforms.

A notable example involves a widespread vulnerability in various JWT libraries regarding the handling of the kid (Key ID) parameter in the JWT header. The kid tells the application which key from the JWKS to use for signature verification. In some vulnerable implementations, the application used the kid value directly in an SQL query or a file path lookup without sanitization.

An attacker could craft an ID Token with a malicious kid value, such as ../../../../etc/passwd or ' UNION SELECT.... If the application used this value in a database query to find the key, it resulted in an SQL Injection vulnerability. If it used it in a file path, it led to a Directory Traversal attack, allowing the attacker to force the application to use an arbitrary file (like /dev/null, which has predictable contents) as the verification key, allowing them to forge valid tokens.

Another common real-world scenario involves enterprise Single Sign-On (SSO) integrations. A company integrates a SaaS application using OIDC. The SaaS application developers correctly verify the JWT signature but fail to map the sub (subject identifier) correctly. Instead of using the unique sub claim (which is an immutable, opaque string like 1048593), they map the user based solely on the email claim.

An attacker, who is a former employee, still has access to the corporate IdP but their specific application access was revoked. The attacker creates a new, personal account on the SaaS application. They then exploit a flaw in the corporate IdP (or perhaps an external IdP if allowed) to change the email address associated with their account to match the email of a current, highly privileged executive. When the attacker logs in via OIDC, the SaaS application sees the executive's email in the verified ID Token and logs the attacker into the executive's account, bypassing all intended access controls. This highlights the danger of relying on mutable claims like email instead of the immutable sub claim for identity mapping.

Securing OIDC implementations requires a rigorous, defense-in-depth approach to token validation and protocol adherence.

Use Established, Vetted Libraries: Never write custom JWT parsing or validation logic. Utilize robust, heavily tested, and actively maintained JWT libraries specific to your programming language. Ensure these libraries are kept up-to-date to patch known vulnerabilities (like the alg: None or signature confusion flaws).

Enforce Strict JWT Validation: The Client application must explicitly configure its JWT library to enforce strict validation rules.

• Whitelist Algorithms: Explicitly define the accepted signature algorithms (e.g., ONLY RS256). The library must reject any token using alg: None or an unexpected symmetric algorithm if an asymmetric one is expected.
• Validate All Critical Claims: The application must explicitly verify the iss (Issuer) exactly matches the expected IdP. It must verify the aud (Audience) exactly matches the application's client_id. It must verify the exp (Expiration) to ensure the token is still valid.
• Do Not Trust Header Parameters: Never blindly trust the jku, jwk, or x5u headers to fetch public keys. Keys should be fetched exclusively from the trusted, hardcoded Discovery Endpoint (/.well-known/openid-configuration) of the verified Issuer.

Implement and Validate the nonce: For any OIDC flow that returns the ID Token directly to the browser, the use of the nonce parameter is absolutely mandatory. Generate a cryptographically secure nonce, bind it to the session, and strictly verify it against the nonce claim in the returned ID Token to prevent replay attacks.

Map Identities Correctly: When establishing a user session based on an ID Token, always use the sub (Subject) claim as the primary, unique identifier for the user. Do not rely solely on the email claim, as emails can be mutable or potentially spoofed depending on the IdP's configuration.

Prioritize the Authorization Code Flow: Just as with OAuth 2.0, the Implicit flow in OIDC is inherently risky. Always default to using the Authorization Code flow (with PKCE) for OIDC. In this flow, the ID Token is retrieved directly via a secure, back-channel server-to-server request, significantly reducing the risk of token interception or manipulation in the browser.