Stop juggling OAuth client IDs and secrets
Adding another sign-in button shouldn't mean maintaining another provider integration. Here's which credentials your app can hand off, and which one still belongs on your backend.
Read articleAll field notes
Posts by Gabe
One secret for all your app's sign-in providers
Google and GitHub sign-in can use the same project credentials. Multiple independent apps should still have separate projects. The useful simplification is fewer provider integrations, not a secret shared everywhere.
Read articleOne profile format doesn't mean one identity
Google and GitHub return different profile data. A normalized response makes that data easier to use, but your account model still needs a stable subject, nullable fields, and deliberate account linking.
Read articleA profile token, not a pass to someone's account
An AnyOAuth token retrieves one signed-in user's profile. It doesn't read their inbox, fetch their repositories, or keep them logged into your app. That smaller boundary is intentional.
Read articleSocial sign-in ends where your app's session begins
A verified profile tells your backend who arrived. Your application still decides which user record that identity maps to, what they can do, and how their session ends.
Read articleSocial sign-in without password handling
Social sign-in removes a password database from this login flow, not the responsibility to protect people’s data. Here’s an ownership inventory you can use before connecting a familiar account to your app.
Read articleFamiliar accounts, one sign-in integration
Google and GitHub can share your application’s callback and profile contract without becoming interchangeable identities. This note separates the provider choice users see from the integration and account decisions your backend owns.
Read articleRedirect, exchange, profile: trace the login boundary
A successful redirect is only the middle of a login. Follow the browser, backend, AnyOAuth, and provider through a numbered contract that ends with your own user record and session.
Read articleSecure OAuth handoffs need separate checks
State, PKCE, callback matching, and a backend secret protect different parts of a login. Use this failure-oriented review to check the handoff without mistaking any one safeguard for a complete session system.
Read articleBefore you add social sign-in, write the app contract
Choose social sign-in by the identity, session, and access requirements your app actually has. These questions turn the homepage FAQ into decisions you can give a teammate or coding assistant before implementation.
Read articleWhat is OAuth? Follow the permission, not the login button
OAuth 2.0 is an authorization framework that lets an application obtain limited access to an API without taking the user’s password. To understand a social login built around it, separate the API permission, the evidence of identity, and the session your app creates afterward.
Read articleOAuth vs OIDC: API access and identity are different contracts
OAuth 2.0 defines how an app obtains permission to access resources; OpenID Connect adds a standard way to verify the user’s identity on top of OAuth. Choose OAuth for delegated API access, and OIDC when your app needs interoperable evidence of who signed in.
Read articleOAuth vs SAML: choose by the boundary you need to cross
OAuth delegates access to APIs; SAML exchanges assertions about identity and is used for federated sign-in. For a login-protocol decision, compare SAML with OpenID Connect, then handle any delegated API access as a separate OAuth requirement.
Read articleAuthorization code flow: inspect the redirect, exchange, and session
The authorization code flow returns a short-lived code through the browser, then exchanges that code for tokens at the authorization server’s token endpoint. Use PKCE to bind redemption to the initiating transaction, and keep your app’s session creation separate from both steps.
Read articlePKCE: what the verifier proves, and what it does not
PKCE, or Proof Key for Code Exchange, binds authorization-code redemption to a secret verifier created for that transaction. With S256, the authorization request sends a SHA-256-derived challenge, and the token request must supply the original verifier; an intercepted code alone is insufficient.
Read article