OAuth 2.0 is an open authorization framework that lets a third-party application obtain limited access to a user's resources on another service — without ever seeing the user's password. It is the industry-standard protocol powering 'Sign in with Google', 'Connect with GitHub', and countless API integrations.
OAuth 2.0 is an authorization protocol defined in RFC 6749 that separates authentication (who you are) from authorization (what you can do). It issues short-lived access tokens to client applications so they can act on behalf of a resource owner. Critically, the user's credentials are only ever entered at the authorization server — never shared with the third-party client. OAuth 2.0 is not an authentication protocol by itself; OpenID Connect (OIDC) is a thin identity layer built on top of it for login use cases.
OAuth 2.0 defines four roles: the Resource Owner (the user), the Client (the app requesting access), the Authorization Server (issues tokens, e.g. Auth0 or Google), and the Resource Server (the API holding protected data). The framework also introduces scopes — strings like 'read:email' or 'repo' — that define exactly what permissions are being requested. A well-designed scope strategy enforces the principle of least privilege, ensuring clients only get the access they truly need.
The Authorization Code Flow is the most secure and widely used grant type for server-side and single-page apps. First, the client redirects the user to the authorization server with a client_id, requested scopes, and a redirect_uri. After the user consents, the authorization server returns a short-lived authorization code to the redirect URI. The client then exchanges that code — along with its client_secret on the server side — for an access token and optionally a refresh token, keeping secrets out of the browser.
The Client Credentials grant is used for machine-to-machine communication where there is no human user involved; the client authenticates directly with its own credentials to receive a token. The Device Authorization grant supports input-constrained devices like smart TVs by displaying a user code on screen and polling for approval. The legacy Implicit and Resource Owner Password Credentials grants are now deprecated in OAuth 2.1 due to significant security weaknesses and should not be used in new systems.
Proof Key for Code Exchange (PKCE, pronounced 'pixie') is a mandatory extension for public clients such as mobile apps and SPAs that cannot safely store a client_secret. The client generates a random code_verifier, hashes it into a code_challenge, and sends the hash with the authorization request. When exchanging the code for a token, it sends the original verifier; the server re-hashes and compares, proving the requester is the same entity that started the flow. Without PKCE, authorization codes intercepted by a malicious app on the same device can be redeemed for tokens.
Always validate the state parameter on redirect to prevent cross-site request forgery (CSRF) attacks that trick users into authorizing a session they did not initiate. Access tokens should be short-lived (minutes to an hour) while refresh tokens should be stored securely and rotated on every use with refresh token rotation enabled. Store tokens in server-side sessions or secure HttpOnly cookies rather than localStorage, which is accessible to any JavaScript on the page. Regularly audit your registered redirect URIs — even a single open redirect vulnerability can allow token hijacking.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app