OAuth, Explained: How Authorizing a Social Account Actually Works

OAuth 2.0 is an authorization framework, not an authentication one — a distinction that trips people up constantly. It doesn't prove who a user is; it lets a user grant a third-party application limited access to their data on another service, without ever sharing their password with that application. The standard defines four roles: the resource owner (the person granting access), the client (the app requesting it), the authorization server (which issues tokens), and the resource server (which holds the actual data and accepts those tokens).

The output of a successful OAuth flow is an access token — a credential the client can present to the resource server on the user's behalf, scoped to only the permissions the user approved, and revocable at any time without changing the user's password.

The most common OAuth 2.0 flow — the authorization code grant — has three steps. First, the client redirects the user's browser to the authorization server's consent screen, where the user sees exactly what access is being requested and approves or denies it. Second, if approved, the authorization server redirects the browser back to the client with a short-lived authorization code in the URL. Third, the client's backend exchanges that code for an access token (and usually a refresh token) by calling the authorization server directly, authenticating itself with a client secret that never touches the browser.

That last step matters: the code itself is not the access token, and it's useless without the client secret, so a code intercepted in transit — say, from a browser history or a referrer header — can't be redeemed by anyone who doesn't also hold that secret.

Before OAuth was widely adopted, connecting a third-party app to a social account often meant literally typing your username and password into that app's own form — a pattern security people call password anti-pattern for a reason: the app can now do anything your account can do, forever, until you change your password everywhere. OAuth's scope model fixes that by letting a platform grant narrow, named permissions — publish content, read comments, manage messages — instead of all-or-nothing account access, and by making revocation a one-click action on the platform's own settings page rather than a password reset.

Concretely: your product sends the user to the platform's authorization URL with the specific scopes it needs (publish rights, not DM access, for example). The user logs in on the platform's own domain — never yours — and approves. The platform redirects back to a URL your product registered in advance, carrying an authorization code. Your backend exchanges that code for an access token and, on most platforms, a refresh token for renewing access once the original token expires. From that point on, publishing on the user's behalf means attaching that access token to API calls — no password ever passed through your systems.

Access tokens expire — sometimes in hours, sometimes in months — and refresh tokens can be revoked by the user or the platform without warning, which is the single most common reason a connected social account suddenly stops publishing. See why social accounts keep disconnecting and how token refresh actually works for the failure modes this standard flow doesn't warn you about up front.

PostGate implements the flow above so your product doesn't have to: one POST /api/profiles/connect call returns a short-lived, branded connection URL (it expires after 15 minutes). Redirect your customer there, and PostGate handles the authorization redirect, the provider's callback, and token storage and refresh end to end — your product only receives the result. See how hosted OAuth removes the callback route from your side of the integration, and the authentication and environments guides for how API keys and branded connect surfaces fit around it.