Why more dev tools are dropping email/password for Google or GitHub sign-in

If you've signed up for a new dev tool in the last two years, there's a good chance you never typed a password. You clicked "Continue with GitHub," approved a permission screen, and you were in. That's not an accident or a cost-cutting shortcut. Password-only signup is disappearing from developer tools because it creates a security liability (credential storage, reset flows, phishing surface) for a population that already has a strong identity provider sitting right there: their GitHub or Google account.

The short answer

Dev tools skip email/password because developers already have a GitHub identity, and GitHub (or Google) has already solved the hard parts of authentication: breach detection, 2FA, session revocation, recovery flows. A tool that builds its own password system is reinventing infrastructure that a) is genuinely hard to get right and b) developers don't want to deal with anyway. OAuth sign-in also cuts signup friction, which matters more to a CLI tool or API product than it does to a consumer app, because the buyer and the user are frequently the same person making a fast decision.

What password auth actually costs a small dev tool

It's worth being specific about what "just add a login form" implies, because it's more than a form.

• Password storage: bcrypt or argon2, per-user salts, and a plan for what happens if the hash table leaks anyway
• Reset flows: token generation, expiry, email delivery, and the abuse case where reset becomes an account-takeover vector
• Credential stuffing: dev tools are a high-value target because a compromised account often has API keys behind it, so you need rate limiting and anomaly detection from day one
• Email deliverability: verification and reset emails landing in spam is a real support burden for a two-person team
• Compliance surface: storing passwords at all pulls you into a stricter security review than delegating to an identity provider does

None of that is exotic. All of it is work that has nothing to do with the actual product. For a small team shipping a CLI or a proxy, every week spent on password reset emails is a week not spent on the thing developers are actually paying for.

Why GitHub and Google specifically

For a developer tool, GitHub sign-in is close to free identity verification. If someone has a GitHub account with commit history, you already know more about them as a legitimate developer than an email/password form would ever tell you. Google sign-in covers the rest: people whose primary identity is a work or personal Google account rather than GitHub, plus it comes with Google's own fraud and bot detection baked in.

Both providers also push the account recovery problem back onto infrastructure that already handles it well. If a developer loses access to their GitHub account, that's a GitHub problem with GitHub's own recovery flow, not a support ticket to a five-person startup that has no way to verify identity beyond "reply to this email."

The best password is the one your product never has to store.

The tradeoff nobody advertises

OAuth-only sign-in isn't free of downsides, and it's worth naming them instead of pretending this is a strictly-better move.

• You're now dependent on a third party's uptime. If GitHub's OAuth endpoint has an incident, nobody can sign into your tool either, and that's out of your control.
• Account linking gets messier. A user who signs up with GitHub and later wants to switch to Google (or vice versa) needs a real merge flow, or they end up with two accounts and no idea why their data looks empty.
• It excludes anyone who deliberately avoids linking third-party logins, including some security-conscious users who see broad OAuth scopes as their own kind of risk.
• The permission screen itself can overreach. Some integrations ask for more GitHub scope than the actual product needs, which is a legitimate thing to be suspicious of before clicking approve.

That last point is the one worth actually checking before you approve anything: does this tool need read access to your private repos, or does it just need to know your GitHub username and email to create an account? A lot of OAuth requests ask for more than the product uses, and there's rarely a prompt that explains why.

What this means for your account security

For you as a developer, OAuth-only sign-in is generally a security upgrade, with one caveat: your GitHub or Google account is now a single point of failure for every tool that trusts it. That makes 2FA on your identity provider non-negotiable, not optional. If your GitHub account gets compromised and it's the sign-in method for six other tools, the blast radius is six tools, not one leaked password reused three places (though that's exactly the failure mode OAuth is trying to eliminate in the first place).

The practical checklist:

• Turn on hardware-key or authenticator-app 2FA on GitHub and Google, not SMS
• Periodically review connected OAuth apps in your GitHub and Google account settings and revoke ones you don't recognize or no longer use
• Check the scopes requested at signup, not just at first click but if the tool later asks to re-authorize with broader access
• Prefer tools that ask for identity-only scope (email, username) over ones that request full repo or org access without a clear reason

Where Probe0 fits

I run into this exact tradeoff building Probe0, a local proxy that sits between coding agents (Claude Code, Codex, Cursor) and the model providers they call, doing caching and routing entirely on your machine. The account system is new, and I picked Google/GitHub sign-in for the same reason argued above: I don't want to be in the business of storing passwords for a tool whose entire pitch is reducing what leaves your machine. There's no Probe0 server processing your prompts, and I'd rather not build a parallel credential store just to gate a dashboard.

It's a small, honest tradeoff. You're trusting Google or GitHub's identity layer instead of trusting me to run a password database correctly, and for a one-person private beta, that's the safer bet on both sides.

The bigger pattern

This shift tracks a broader move in developer tooling toward doing less custom infrastructure and trusting proven building blocks instead, the same instinct that pushes teams toward managed Postgres over self-hosted, or toward existing observability platforms over homegrown logging. Password auth is infrastructure. Most dev tools don't need to own it, and increasingly, they've stopped pretending they do.