Quartz 4

OpenID Connect (OIDC) & OAuth 2.0

4 min read

Tags: web-security authentication authorization OIDC OAuth2 pentesting #protocol passwords vulnerability

1. Core Definitions: The “Auth” Difference

The most critical distinction for pentesting is understanding what each protocol is actually built to do.

  • OAuth 2.0 (Authorization): A framework that allows a user to grant a third-party application limited access to their resources on another site without exposing their credentials.

    • Analogy: A hotel keycard. It grants access to specific rooms (scopes), but doesn’t tell the door who you are.

  • OpenID Connect (Authentication): An identity layer built directly on top of the OAuth 2.0 protocol. It allows the client application to verify the identity of the end-user based on the authentication performed by an Authorization Server.

    • Analogy: A passport. It proves your identity to the hotel desk clerk.

2. How OIDC Integrates with OAuth 2.0

OIDC piggybacks on OAuth 2.0 flows. You trigger OIDC by including openid in the OAuth scope parameter.

When OIDC is used, the Authorization Server returns an ID Token alongside the standard OAuth Access Token.

Key Components

  • Relying Party (RP): The client application trying to authenticate the user.

  • OpenID Provider (OP) / Identity Provider (IdP): The server authenticating the user (e.g., Google, Okta, Azure AD).

  • ID Token: A securely signed JSON Web Token (JWT) that contains claims (assertions) about the authenticated user’s identity (e.g., sub for user ID, email, exp for expiration).

  • UserInfo Endpoint: An API endpoint provided by the OP that the RP can call (using the Access Token) to retrieve additional user profile data.

OpenID Connect flow diagram, AI generated

Shutterstock

3. The Standard OIDC Flow (Authorization Code Flow)

The most common and secure flow you will encounter.

  1. RP to OP: The RP redirects the user to the OP with response_type=code and scope=openid profile email.

  2. Authentication: The user authenticates with the OP and grants consent.

  3. Code returned: OP redirects back to the RP’s redirect_uri with an Authorization Code.

  4. Token Exchange (Backchannel): RP sends the Code to the OP’s token endpoint (authenticating itself using its Client ID/Secret).

  5. Tokens Issued: OP validates the code and returns an Access Token and an ID Token.

  6. Identity Confirmed: RP validates the ID Token’s signature and claims to log the user in.

4. Pentesting Focus Areas & Attack Vectors

When assessing an application using OIDC/OAuth, check for these common misconfigurations:

A. Redirect URI Manipulation

  • Vulnerability: If the redirect_uri parameter is not strictly validated by the OP, an attacker can alter it to point to a server they control.

  • Impact: Stealing the Authorization Code or Implicit tokens, leading to account takeover.

  • Bypass techniques: Check for exact match vs. wildcard matching, directory traversal (https://legit.com/auth/../malicious), or domain suffix manipulation.

B. CSRF (Cross-Site Request Forgery)

  • Vulnerability: Missing, predictable, or unvalidated state or nonce parameters.

  • Impact: An attacker can trick a victim’s browser into completing an OIDC flow with the attacker’s credentials, linking the victim’s account to the attacker’s IdP account.

C. JWT Vulnerabilities (ID Token)

  • Vulnerability: Since the ID Token is a JWT, all standard JWT attacks apply.

  • Checks: * Does the RP accept tokens with alg=none?

    • Is the signature actually being verified by the RP?

    • Can you forge a token using a weak HMAC secret?

    • Can you manipulate the kid (Key ID) header to point to an attacker-controlled file/URL?

D. Implicit Flow Token Leakage

  • Vulnerability: In the Implicit Flow (response_type=id_token token), tokens are returned in the URL fragment (#).

  • Impact: Tokens can be leaked via the Referer header, browser history, or malicious JavaScript (XSS) on the page.

E. Token Replay / Confusion

  • Vulnerability: The RP fails to validate the aud (audience) claim or the iss (issuer) claim in the ID Token.

  • Impact: An attacker could take a valid ID token generated for Client A and submit it to Client B to log in as the victim.

F. Dynamic Client Registration (SSRF)

  • Vulnerability: If the OP supports dynamic client registration (allowing RPs to register themselves automatically), the endpoints might be vulnerable.

  • Impact: SSRF via the logo_uri or jwks_uri fields, or mass assignment vulnerabilities.

OpenID Connect (OIDC) with OAuth allows applications to authenticate users using third-party identity providers (IdPs). If dynamic registration is enabled, attackers can abuse this feature to capture and replay authentication requests.
Replay Attack

Graph View