How OAuth login works
OAuth lets a user give an app limited access to their account without giving the app their password. The app sends the user to the provider, the provider asks the user, and the app receives a one-time code it swaps for tokens.
The steps in plain words
The app redirects the browser to the provider with its client id, the permissions it wants (scopes) and a random state value. The user signs in at the provider, never at the app, and approves the request.
The provider redirects back to the app with a short-lived code. The app's server sends that code, together with its client secret, straight to the provider and receives an ID token (who the user is) and an access token (what the app may do).
Why a code and not the token directly
The redirect passes through the browser, which can leak URLs through history or logs. A one-time code is useless without the client secret, so the real tokens travel only over the server-to-server call.
Common mistakes
Skipping the state check lets an attacker trick a user into logging in to the attacker's account. Putting the client secret in front-end code exposes it to everyone. Asking for more scopes than needed makes users refuse and widens the damage of a leak.
Questions
Is OAuth the same as login?
OAuth is about authorisation, giving an app limited access. Sign-in uses OpenID Connect, a layer on top of OAuth that adds the ID token describing the user.
What is the state parameter for?
A random value the app creates before the redirect and checks when the user returns. It proves the response belongs to a request the app started.
Does the app see my Google password?
No. You enter it only on the provider's own page.
What is a refresh token?
A longer-lived token the app can use to get a new access token without asking the user again. It must be stored securely.