Your "Sign in with Google" button builds a public URL. What's in it?

When someone clicks "Sign in with GitHub" on your site, nothing secret happens first. Their browser navigates to a URL your own page assembled, something like https://github.com/login/oauth/authorize?response_type=...&redirect_uri=...&client_id=.... That URL is in plain sight. It's in the link's href, in the network tab, in the address bar the instant the redirect fires. Anyone can read it, including you.

So read it. The whole OAuth handshake starts with that one request, and three things you can see in it decide whether your users' login tokens come back to a place you control or somewhere else entirely. None of them require breaking your auth code. They're spelled out in the query string.

OAuth 2.1 dropped the implicit grant from the spec outright. Not deprecated with a polite migration window, removed. The reason is sitting in the response_type parameter, and if your authorize URL still carries a bare token, you're building the flow the standard threw away.

What the parameters are telling an attacker

Start with the response type. response_type=token (or id_token token) is the implicit grant. It tells the provider to send the access token straight back in the URL fragment of your redirect, like https://yoursite.com/cb#access_token=ya29.... That fragment is a token, in a URL, in a browser. Browser history keeps it. The Referer header can carry it to whatever third-party script or analytics beacon your callback page loads. Server logs and proxy logs along the way capture full URLs as a matter of course. The token was supposed to be a secret between the provider and your backend. The implicit grant pastes it into the one place everything reads.

The code and code id_token flows do not have this problem. Those return a short-lived authorization code that's useless without your client secret, exchanged server-side over a back channel the browser never sees. The bare token is the one to fear.

Next, the redirect_uri scheme. If it reads http://, the provider returns the code or token over an unencrypted connection. That's the same shared-network problem that makes plain HTTP still answering dangerous, except the thing crossing the wire in the clear is a live credential. Someone on the coffee-shop Wi-Fi watching plaintext go by reads the callback and walks off with the session.

Then the redirect_uri host. OAuth providers only return tokens to redirect URIs you've registered, which is the allowlist that's supposed to keep this safe. But allowlists get loose. A wildcard subdomain, a stale entry, a path that wasn't pinned. If your authorize URL points redirect_uri at a domain that isn't yours, an attacker who can craft an authorize link sends your user's code to their host. The user sees the real provider's consent screen, approves the login they meant to do, and the code lands on the attacker's callback. Their account, the attacker's hands.

The params that matter, in order

These are the three signals worth reading off any authorize URL your site builds:

The first two are high severity because they expose a token or code directly. The cross-domain redirect is medium: it needs a loose allowlist on the provider's side to become exploitable, but when it does, it's an account takeover with no malware and no phishing page, just a crafted link.

The fix is the authorization code flow

All three problems have the same answer, and it's the flow the spec now mandates. Use response_type=code with PKCE. The provider returns a code in the URL, PKCE binds that code to the request so a stolen code is useless, and your backend exchanges it for the token out of the browser's sight. Make the redirect_uri https://, and make it a path on your own registrable domain.

response_type=token
redirect_uri=http://yoursite.com/callback

While you're confirming the callback handler, check that the session cookie it sets carries HttpOnly, Secure, and SameSite. A clean OAuth flow that drops the token into a readable cookie has just moved the leak one step downstream.

SurfaceCheckr reads the authorize URL your own page builds, the login link and the redirect it points at, passively. It never completes a login, never sends a credential, never tests your token validation or your auth logic. It just parses the query string the way the browser would: it tells the safe code and code id_token flows apart from the bare token implicit grant, flags an http:// redirect, and flags a redirect_uri on a domain that isn't yours (localhost and private addresses excluded, since those are local dev, not exposure). That's the outside view, not a pentest.

Click your own sign-in button and look at where it sends you. If the URL says response_type=token, the standard already told you what to do with it.