<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>AnyOAuth field notes</title><link>https://anyoauth.com/blog/</link><description>Auth you can inspect. Practical guides for developers and AI-assisted builders.</description><language>en</language><item><title>Stop juggling OAuth client IDs and secrets</title><link>https://anyoauth.com/blog/stop-juggling-oauth-client-ids-and-secrets/</link><guid isPermaLink="true">https://anyoauth.com/blog/stop-juggling-oauth-client-ids-and-secrets/</guid><description>Adding another sign-in button shouldn&apos;t mean maintaining another provider integration. Here&apos;s which credentials your app can hand off, and which one still belongs on your backend.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>Building with AnyOAuth</category></item><item><title>One secret for all your app&apos;s sign-in providers</title><link>https://anyoauth.com/blog/one-secret-all-your-apps-sign-in-providers/</link><guid isPermaLink="true">https://anyoauth.com/blog/one-secret-all-your-apps-sign-in-providers/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>Building with AnyOAuth</category></item><item><title>One profile format doesn&apos;t mean one identity</title><link>https://anyoauth.com/blog/one-profile-every-provider/</link><guid isPermaLink="true">https://anyoauth.com/blog/one-profile-every-provider/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>Building with AnyOAuth</category></item><item><title>A profile token, not a pass to someone&apos;s account</title><link>https://anyoauth.com/blog/a-profile-token-not-a-provider-token/</link><guid isPermaLink="true">https://anyoauth.com/blog/a-profile-token-not-a-provider-token/</guid><description>An AnyOAuth token retrieves one signed-in user&apos;s profile. It doesn&apos;t read their inbox, fetch their repositories, or keep them logged into your app. That smaller boundary is intentional.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>Building with AnyOAuth</category></item><item><title>Social sign-in ends where your app&apos;s session begins</title><link>https://anyoauth.com/blog/your-app-owns-the-session/</link><guid isPermaLink="true">https://anyoauth.com/blog/your-app-owns-the-session/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>Building with AnyOAuth</category></item><item><title>Social sign-in without password handling</title><link>https://anyoauth.com/blog/social-sign-in-without-password-handling/</link><guid isPermaLink="true">https://anyoauth.com/blog/social-sign-in-without-password-handling/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>Building with AnyOAuth</category></item><item><title>Familiar accounts, one sign-in integration</title><link>https://anyoauth.com/blog/familiar-accounts-one-sign-in-integration/</link><guid isPermaLink="true">https://anyoauth.com/blog/familiar-accounts-one-sign-in-integration/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>Building with AnyOAuth</category></item><item><title>Redirect, exchange, profile: trace the login boundary</title><link>https://anyoauth.com/blog/redirect-exchange-profile/</link><guid isPermaLink="true">https://anyoauth.com/blog/redirect-exchange-profile/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>Building with AnyOAuth</category></item><item><title>Secure OAuth handoffs need separate checks</title><link>https://anyoauth.com/blog/secure-oauth-handoffs/</link><guid isPermaLink="true">https://anyoauth.com/blog/secure-oauth-handoffs/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>Building with AnyOAuth</category></item><item><title>Before you add social sign-in, write the app contract</title><link>https://anyoauth.com/blog/before-you-add-social-sign-in/</link><guid isPermaLink="true">https://anyoauth.com/blog/before-you-add-social-sign-in/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>Building with AnyOAuth</category></item><item><title>What is OAuth? Follow the permission, not the login button</title><link>https://anyoauth.com/blog/what-is-oauth/</link><guid isPermaLink="true">https://anyoauth.com/blog/what-is-oauth/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>OAuth fundamentals</category></item><item><title>OAuth vs OIDC: API access and identity are different contracts</title><link>https://anyoauth.com/blog/oauth-vs-oidc/</link><guid isPermaLink="true">https://anyoauth.com/blog/oauth-vs-oidc/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>OAuth fundamentals</category></item><item><title>OAuth vs SAML: choose by the boundary you need to cross</title><link>https://anyoauth.com/blog/oauth-vs-saml/</link><guid isPermaLink="true">https://anyoauth.com/blog/oauth-vs-saml/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>OAuth fundamentals</category></item><item><title>Authorization code flow: inspect the redirect, exchange, and session</title><link>https://anyoauth.com/blog/authorization-code-flow/</link><guid isPermaLink="true">https://anyoauth.com/blog/authorization-code-flow/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>OAuth fundamentals</category></item><item><title>PKCE: what the verifier proves, and what it does not</title><link>https://anyoauth.com/blog/pkce/</link><guid isPermaLink="true">https://anyoauth.com/blog/pkce/</guid><description>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.</description><pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate><dc:creator>Gabe</dc:creator><category>OAuth fundamentals</category></item></channel></rss>