What are OAuth 2.0 and OpenID Connect?

OAuth 2.0 is a framework for delegated authorization: an application receives limited access to resources without learning the user's password. OpenID Connect (OIDC) adds a standardized identity layer for login and single sign-on. The terms are often mixed up, but solve different problems.

How do OAuth and OpenID Connect differ?

An access token targets an API and is not a general identity assertion. OIDC supplies an ID token and defined claims for this purpose. Conversely, an ID token should not replace an access token for arbitrary API calls.

Which roles and tokens exist?

The resource owner is usually the user. The client requests access, the authorization server authenticates and issues tokens, and the resource server protects the API. Access tokens carry permissions and audience; refresh tokens obtain new access tokens. OIDC adds ID tokens, UserInfo, discovery metadata and the nonce mechanism. Tokens can be JWTs, but need not be.

How does Authorization Code Flow work?

1. The client redirects the browser with client ID, redirect URI, scope, state and possibly nonce to the authorization server.
2. The user authenticates and consents to requested permissions.
3. The browser receives a short-lived code at the exactly registered redirect URI.
4. The client exchanges it at the token endpoint; PKCE binds the code to the initiating client.
5. The client validates tokens and claims and uses the access token only at its intended resource server.

Which vulnerabilities occur?

• Loose redirect URI validation sends codes or tokens to an attacker.
• Missing or incorrectly bound state enables login CSRF and account linking attacks.
• Missing PKCE exposes intercepted authorization codes for unsuitable clients.
• Issuer, audience, signature, nonce or token type is not fully validated.
• Overbroad scopes, long-lived tokens or exposed refresh tokens increase impact.
• Accounts are merged based only on an unverified email address.

How is an implementation secured?

New clients should use Authorization Code with PKCE. Redirect URIs are fully pre-registered, tokens travel over secure backchannels and are not logged in URLs. state protects the transaction and OIDC nonce binds the ID token. Clients request only necessary scopes. Maintained libraries and trusted discovery metadata reduce custom code, but do not replace secure configuration.

Flow example: bind state and PKCE to the same session

state = randomBytes(32)
verifier = randomBytes(32)
challenge = base64url(sha256(verifier))

session.store('oauth_state', state)
session.store('pkce_verifier', verifier)

redirectToAuthorizationServer({
  response_type: 'code',
  state: state,
  code_challenge: challenge,
  code_challenge_method: 'S256'
})

if callback.state != session.take('oauth_state'):
    rejectLogin()

tokens = exchangeCode(callback.code, {
  code_verifier: session.take('pkce_verifier'),
  redirect_uri: EXACT_REGISTERED_URI
})

The values are random, single-use, short-lived and bound to the specific browser session. An OIDC login additionally uses a nonce, which is compared with the ID Token claim after signature verification.

What does a security test examine?

Testing treats client, authorization server and resource server as one flow. It examines redirect manipulation, CSRF binding, PKCE, token confusion, claim validation, scope escalation, account linking, logout and revocation. Multiple users and clients are necessary to establish whether codes, tokens or identities can be swapped between security contexts.