How do OAuth 2.0 and OpenID Connect authentication and authorisation flows work?

How the OAuth 2.0 flow is structured

OAuth 2.0 is best understood as a delegation protocol, not a user authentication protocol. The core flow separates the client, the authorisation server, and the resource server so that the user can grant limited access without handing credentials to the client. That separation is what makes redirect handling, code exchange, token scope, and audience boundaries so important.

The most common browser-based pattern is the authorisation code flow. The client sends the user to the authorisation server, the user authenticates there, and the authorisation server returns an authorisation code to the registered redirect URI. The client then exchanges that code for access tokens, and sometimes refresh tokens, to call APIs on the user’s behalf.

Good implementations treat the code as short-lived and the token as narrowly scoped. Redirect URIs must be exact, not loosely matched, because a weak redirect check can turn the flow into a token theft problem. Scope selection should be minimal, and token handling should keep access tokens out of logs, browser storage, and any place where an attacker could replay them.

How OpenID Connect adds authentication on top of OAuth 2.0

openid connect layers identity proofing on top of OAuth 2.0 by introducing the OpenID Connect Core 1.0 concept of an ID token. OAuth alone answers “what can this client access?”, while OIDC also answers “who just signed in?”. That distinction matters because an access token is for APIs, but an ID token is for the client’s sign-in state and user identity claims.

In practice, OIDC still uses the OAuth authorisation code flow, but the token response includes identity data and the client must validate more than the fact that a token arrived. It should verify the issuer, audience, nonce, signature, and other token properties before trusting the login result. If those checks are weak, the application can accept a forged or replayed login even though the authorisation flow itself completed correctly.

OIDC is also where session creation usually happens. After validating the ID token, the client creates its own application session and then tracks that session separately from the upstream identity provider. That separation prevents a confusing, and often dangerous, assumption that “having a token” is the same thing as “being authenticated for this app”.

Which implementation details matter most in real deployments

The parts that most often determine whether the flow is secure are the ones around token issuance, token use, and token lifecycle. For stronger deployments, RFC 6749: The OAuth 2.0 Authorization Framework defines the baseline flow, while the newer security guidance around sender-constrained tokens, token audience restriction, and code interception defence helps reduce replay risk.

That is why redirect URI precision, PKCE, state validation, and correct client registration matter so much. They reduce the chance that an attacker can intercept the code, swap the destination, or trick the client into accepting a response that was not meant for it. On the token side, audience restriction and sender-constraining help keep a stolen token from being useful outside the intended context.

For sign-in journeys, NIST SP 800-63 Digital Identity Guidelines is a useful reference point for authentication assurance, especially when you need to decide how strong the upstream login should be before you trust the resulting session. That is especially relevant when the app is using social login, federation, or workforce SSO and must decide whether to step up authentication for sensitive actions.

Risk and Threat Considerations

OAuth and OIDC failures usually show up as trust-boundary failures, not abstract protocol mistakes. A misconfigured redirect URI, weak client validation, or careless token storage can let an attacker steal an authorisation code or replay a token, then inherit the access that the user or service was meant to have.

Failure mechanism: The attacker abuses the gap between “the authorisation server issued something” and “the client actually verified that the response belongs to this transaction and this audience”. That gap appears in open redirects, permissive redirect URI matching, missing PKCE, weak token validation, and bearer tokens that can be reused after theft.

Impact: The result can be account takeover, API abuse, session hijacking, or persistent access that looks legitimate to downstream systems. In OIDC deployments, a forged or replayed ID token can also create a false login state, which is often more damaging than simple API misuse because it compromises the application session itself.

Practitioner Guidance

What to verify: Treat redirect URI registration, code exchange, and token validation as three separate checks. If any one of them is “close enough” rather than exact, assume the implementation is fragile and review it before production use.

Decision rule: If the app only needs delegated API access, use OAuth scopes narrowly and do not let ID token claims drive authorisation decisions. If the app needs sign-in, validate the OIDC ID token carefully and then establish a local session with its own expiry and revocation logic.

What practitioners underestimate: The biggest mistake is treating a successful redirect as proof of identity. The redirect only proves that the browser returned from the authorisation server, not that the client has safely verified the user, the audience, the nonce, and the transaction context.

Practitioner takeaway: Secure OAuth and OIDC by making every trust step explicit: exact redirect handling, minimal scopes, strict token validation, and a clear separation between delegated API access and authenticated application session.

Related resources from NHI Mgmt Group

• How should security teams use geo-location signals to adapt authentication decisions in OAuth and OpenID Connect flows?
• Why does JWE matter in OAuth and OpenID Connect flows?
• How should security teams use OpenID Connect alongside OAuth 2.0 in modern application login flows?
• What is the difference between passkeys and OAuth OpenID Connect in customer authentication?