Server-Side OAuth
Server-side OAuth is an OAuth 2.0 flow where the authorization code is exchanged for tokens on a trusted backend, keeping client secrets off the user’s device.
In plain English
When a user signs in with Google, Slack, or GitHub, the OAuth provider hands back an authorization code. That code then has to be exchanged for access and refresh tokens. In server-side OAuth, the exchange happens on your backend — which holds the client secret — not in the browser. The browser only ever sees the short-lived code in the URL; the tokens live only on the server and in the user's session cookie.
The pattern is the default for web apps because it keeps the client secret off the user's machine. Contrast with public-client flows (SPAs, mobile, desktop) that use PKCE because they cannot safely hold a secret. For a hosted web app, server-side OAuth plus refresh-token rotation is the canonical setup.
Why it matters for Black Box
Black Box runs as a hosted web app at www.web4guru.com. Google OAuth for Gmail/Calendar/Drive uses the server-side flow — the API server on Railway holds the client secret and persists encrypted refresh tokens. The browser only sees session cookies.
Examples
- Google OAuth: browser → consent → redirect with code → server exchanges code for tokens → server stores tokens encrypted.
- Slack OAuth: same shape, with scopes negotiated at consent.
- GitHub OAuth: same, with optional refresh tokens and short-lived access tokens.