OAuth

OAuth is an authorization protocol that lets a user grant an app limited, revocable access to their data on another service, without sharing a password. It is the mechanism behind almost every "Sign in with Google" or "Connect your Slack account" button: instead of typing a password into a third-party app, the user approves a scoped permission and the app receives a token it can use on their behalf.

What is OAuth?

OAuth (Open Authorization) separates two things that used to be bundled together: authentication, proving who you are, and authorization, deciding what an app is allowed to do on your behalf. The current version, OAuth 2.0, published in 2012, is the industry standard for delegated access on the web. Before OAuth, connecting one service to another meant handing over a password directly: the third party got unlimited access, the user had no easy way to see what was shared, and revoking access meant changing the password everywhere it was reused. Earlier approaches like HTTP Basic Authentication sent that same static credential on every single request, so a leaked server log or a compromised third-party integration exposed the user's actual password, not just a limited-purpose token.

How the OAuth flow works

A typical OAuth 2.0 exchange (the authorization code flow, the one used by most web and mobile apps) follows four steps: the app redirects the user to the service's login and consent screen, the user approves a specific set of permissions (scopes), the service redirects back with a short-lived authorization code, and the app exchanges that code for an access token on its server. A simplified authorization request looks like this:

GET /authorize?client_id=abc123&redirect_uri=https://app.example.com/callback&response_type=code&scope=read_profile
Authorization: Bearer <access_token>

The access token is what the app actually stores and sends with each API call. It is scoped to specific permissions, has an expiry date, and can be revoked by the user at any time from the service's account settings, without touching their password. Most implementations also issue a longer-lived refresh token alongside it, so the app can silently request a new access token once the old one expires, without forcing the user through the login screen again. Rotating refresh tokens, issuing a fresh one on every use and invalidating the previous one, further limits the damage if a token is ever intercepted in transit.

Main OAuth grant types

• Authorization code: the standard flow for apps with a server-side backend, the most secure option.
• Authorization code with PKCE: the same flow hardened for mobile and single-page apps that cannot keep a secret.
• Client credentials: used for server-to-server calls with no end user involved.
• Refresh token: not a grant on its own, but the mechanism that lets an app get a new access token once the current one expires, without asking the user to log in again.

OAuth vs OpenID Connect vs API key

Best practices and common pitfalls

Always request the narrowest scope the app actually needs: asking for full account access when only a profile picture is required is a common source of user distrust and audit findings. Use the PKCE extension for any app that cannot securely store a client secret, which today means essentially all mobile and single-page apps. Store access and refresh tokens encrypted, never in plain text or in client-side storage that other scripts can read. Set access tokens to expire quickly, typically minutes to a few hours, and lean on refresh tokens for longevity instead of issuing one long-lived access token that stays valid for months. The most frequent mistake is treating an OAuth login as proof of a verified email or identity: OAuth alone only proves the user granted access, OpenID Connect is what adds a verified identity layer on top.

Why OAuth matters

OAuth is what makes the modern pattern of connected apps and integrations possible without every service needing to store everyone's passwords. For a team wiring up automations (a CRM pulling contacts from Gmail, a project tool syncing with Slack) it is the standard way to authorize that connection securely, with an audit trail and a one-click way to cut access later. A marketing team connecting its ad platform to a reporting dashboard, or a support team linking a helpdesk to a CRM, both rely on the same underlying mechanism to move data safely between systems that were never built by the same vendor.

OAuth at BeBranded

We implement OAuth whenever a web application needs to connect to a third-party API on a user's behalf: syncing a calendar, pulling CRM data, or letting a client log in with an existing account instead of creating a new password. It is a standard part of the web applications we build when an integration calls for it.