OAuth, Explained for People Who Have to Ship It
By The Alt Auth Team
OAuth documentation is written for people implementing providers. Almost everyone reading it is instead trying to add a "Continue with Google" button, and the gap between those two audiences is why the topic feels harder than it is.
What is actually happening
You send the user to Google with a note saying who you are and where to send them back. They sign in on Google’s page — your app never sees the password. Google returns them with a short-lived code. Your server exchanges that code, over a back channel, for a token proving who the user is. That is the whole shape of it.
Where it goes wrong
- Doing the code exchange in the browser, which leaks the client secret.
- Skipping the state parameter, which is what stops a cross-site request forgery on the callback.
- Trusting the email claim without checking it is verified — an unverified email is an account takeover waiting to happen.
- Assuming the provider’s user ID is an email address. It is not, and people change their email.
- Forgetting the account-linking case: same human, second provider, two accounts.
“The dangerous part of OAuth is not the protocol. It is the five small decisions the tutorial did not mention.”
Every one of these is handled for you when the provider integration is configuration rather than code. Google OAuth is available on every Alt Auth plan, Free included, with Apple, Facebook and Microsoft on higher plans.