PKCE, Refresh Tokens & OpenID Connect

Confidential vs. Public Clients & PKCE

A confidential client (server-side web app) can hold a secret safely. A public client (mobile app, SPA) can't — its code is visible to the user. PKCE adds a dynamically-generated code verifier/challenge so an intercepted authorization code can't be redeemed by an attacker — now recommended for ALL clients, replacing the older, less-safe Implicit flow that exposed tokens directly in URL fragments.

Refresh Tokens & Revocation

Short-lived access tokens limit damage if leaked; a longer-lived refresh token gets a new access token without re-prompting the user for consent. Revocation lets a user (or the service) invalidate a token immediately — e.g. when a user revokes an app's access in their account settings, rather than waiting for natural expiry.

OpenID Connect (OIDC)

Adds an identity layer on top of OAuth 2.0: an ID token (typically a signed JWT) carries identity claims (name, email). A userinfo endpoint can fetch richer profile data on demand using the access token. "Sign in with Google" buttons are technically OIDC, not plain OAuth.

Client Credentials (Machine-to-Machine)

No end user involved — a backend service authenticates with its own client ID/secret to access resources on its own behalf, not a delegated user's. No consent screen, no redirect.

Redirect URI Validation

Authorization Servers require exact-match, pre-registered redirect URIs to prevent an attacker crafting a request that redirects the code/token to a malicious URL instead of the real app.

Why OAuth Exists

The old "password anti-pattern" (sharing your actual password with a third-party app) gives that app full, unrestricted, unrevokable-without-changing-your-password access. OAuth's scoped, token-based, revocable model fixes each of those specific weaknesses.