Field notes for developers and AI-assisted builders. Fewer credential puzzles, clearer identity boundaries, and a sign-in flow you can explain after the assistant writes it.
Follow via RSSAdding 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.
GabeRead the credential field note15 articles
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.
GabeRead articleGoogle 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.
GabeRead articleAn 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.
GabeRead articleA 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.
GabeRead articleSocial 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.
GabeRead articleGoogle 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.
GabeRead articleA 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.
GabeRead articleState, 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.
GabeRead articleChoose 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.
GabeRead articleOAuth 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.
GabeRead articleOAuth 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.
GabeRead articleOAuth 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.
GabeRead articleThe 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.
GabeRead articlePKCE, 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.
GabeRead articleNo matching articles. Try another term or choose All posts.