Quick answer: OAuth 2.0 and OpenID Connect (OIDC) security is protecting the token flows an application uses to obtain authorization and authenticate on behalf of the user against manipulation. OAuth is used for authorization (permission for an application to access user data), OIDC for authentication (who the user is), and both rely on token exchange. The most common attacks are: token theft from leaving the redirect address unchecked, request forgery from not validating the state parameter, interception of the authorization code, and token validation weaknesses. The root fix is to fix allowed redirect addresses with an exact match, bind the flow with state and PKCE, always validate the token signature and audience, and use the most secure flow type possible.

Today many applications handle login through Google, Apple or a corporate identity provider. This convenience is provided with OAuth and OIDC, but when the flow is set up wrong an attacker can get into another user's account. This article explains the most common flaws in OAuth and OIDC flows and the correct defense.

The difference between OAuth and OIDC

These two are often confused. OAuth 2.0 is an authorization framework: it lets an application obtain limited access to data the user keeps on another service. OIDC is an identity layer built on OAuth: it verifies who the user is and produces an identity token. In short, OAuth answers "can this application access this data", OIDC answers "is this user really them".

The most common OAuth and OIDC attacks

Attack What it does Result
Open redirect redirect_uri unchecked Redirecting the token or code to the attacker
Missing state Flow not bound to the request Request forgery, account linking
Code interception The authorization code is stolen Obtaining a token on behalf of the user
Token validation weakness Signature or audience not checked Accepting a fake or another application's token
Consent screen bypass Abuse of silent re authorization Access without user consent

Open redirect is the most classic OAuth flaw and is logically the same as open redirect: if redirect_uri is not fully validated, the token goes to the attacker.

Redirect and state, two critical points

The two most common mistakes in the OAuth flow are about redirect_uri and state. redirect_uri is the address where the token is sent at the end of the flow; this address must be on a server side allow list with an exact match. A loose match lets the attacker redirect the token to their own address. The state parameter binds the flow to the initiating request; if not validated, the attacker can link their account to the victim's. This is the OAuth equivalent of CSRF protection.

Token validation

The identity token produced in OIDC tells the application who the user is. This token's signature, expiry and audience (which application it was produced for) must always be validated. A token whose signature is not validated can be forged; a token whose audience is not checked can be stolen from another application and used. This is directly related to JWT security, because OIDC tokens are usually in JWT format.

The correct defense

1. Exact match redirect_uri

Allowed redirect addresses must be kept on a server side allow list with an exact match. Substring or wildcard matches must not be used.

2. state and PKCE

Every flow must be bound to the initiating request with the state parameter and, where possible, PKCE. This prevents code interception and request forgery.

3. Validate the token signature and audience

The identity token's signature, expiry and audience must always be validated on the server. An unvalidated token must never be considered trusted.

4. Choose the most secure flow

The most secure flow type possible must be chosen, and old and risky flows that carry the token in the address bar must be avoided.

OAuth and OIDC testing with KAOS

DSET's local AI security engine KAOS tests OAuth and OIDC flows with an evidence first approach. It tries redirect_uri validation with different vectors, measures the absence of state and PKCE, and tests in a controlled way whether token validation checks signature and audience. It verifies whether a flaw actually provides access to another user's account and reports only exploitable findings without false positive noise. This makes your account takeover surface visible at the identity layer.

Frequently asked questions

Are OAuth and OIDC the same thing? No. OAuth is for authorization, OIDC for authentication. OAuth manages an application's access to data; OIDC verifies who the user is and is built on OAuth. Together they form modern login flows.

Why is using a wildcard redirect_uri dangerous? Because a loose match can let an address under the attacker's control be considered valid, and the token is redirected there. redirect_uri must always be on an allow list with an exact match.

Can it work without the state parameter? It should not. State binds the flow to the initiating request and prevents request forgery. Without state the attacker can link their account to the victim's. It is recommended to use it together with PKCE.

Sources

To test your application's OAuth and OIDC login flow for redirect, state and token validation with a working proof, contact DSET. We provide penetration testing and secure code review from our Ankara Hacettepe Teknokent laboratory.