For a long time this blog was me writing about auth while the product was still finding its legs. That chapter is over.

SpartanAuth is live. Not a slide deck. Not a private prototype I only demo on good days. It is running in real applications — including several of my own — and other people are shipping with it too.

The point of SpartanAuth was never “another identity platform with a 40-page pricing grid.” It was simpler: give developers a path to solid auth without turning the front door of their app into a multi-month side quest. The login widget was always part of that bet. Drop it in, brand it, and let users sign in without you hand-rolling every edge case.

Here is what that looks like in the wild.

Real apps, real front doors

Same widget family. Different products. Different brands.

I care about this more than feature checklists. A login screen is the handshake before anyone trusts your app. If it feels bolted on, everything downstream feels a little worse. If it feels native, people stop thinking about auth and start using the product.

What the widget can do today

If you last checked in during the early prototype posts, the surface area has grown up.

The login widget, backed by SpartanAuth, currently supports:

• OAuth2 / social sign-in — Google, Apple, GitHub, and generic OIDC
• Self sign-up
• Password reset
• MFA via email
• Passkeys

That mix matters. Some apps want “Continue with Google” on day one. Some need boring email + password with a reset flow that does not shame the user. Some are ready for passkeys. A few want all of the above without maintaining four half-finished auth codepaths.

I am still opinionated about SMS OTP — I wrote about why I will not pretend it is a strong factor — but I am not opinionated about whether your users should start on OAuth, passwords, or passkeys. The widget is there to make the good options easy to offer.

One more from the wild

Screenshots are useful. This one needed motion — another live SpartanAuth integration, with a background animation I thought was too pretty not to include.

If you have ever integrated auth the hard way, you know the invisible work: redirects, error states, “forgot password” loops, MFA handoffs, provider quirks. The goal here is that most of that complexity lives behind a small embed and a service that already knows how to do it.

Docs, skills, MCP, and shipping with AI

Something I did not fully expect when I started: people are not only reading docs — they are pointing coding agents at them.

The docs live at docs.spartanauth.com. Alongside the usual reference material, there are skills and guidance meant to help humans and AI assistants wire SpartanAuth up without inventing a snowflake architecture every time.

Next up is an MCP server integration. That matters once an agent is past “read the docs” and into actually building. Instead of only generating code that hopes it matches your tenant setup, an agent will be able to apply SpartanAuth settings and manage Sectors as it implements — configure the thing it is integrating, not just describe it. It is not available yet, but it is on the way.

That is a big deal in 2026. A lot of apps are getting scaffolded at unnatural speed. Auth is still one of the places where “move fast” turns into “accidentally store passwords wrong” or “ship a login page that only works on the author’s laptop.” If good docs, skills, and (soon) MCP tools make the secure, boring path the default path for an agent, I will take that win every day of the week.

What I want you to do with this

If you have been waiting for SpartanAuth to feel real: it is.

• Browse the product: spartanauth.com
• Read / point your agent at the docs: docs.spartanauth.com
• If you want updates as more ships, get on the list

I will keep writing here the way I have been — practical notes, honest boundaries, fewer buzzwords than the category usually deserves. The difference is that now the screenshots are not mockups. They are front doors on software people already use.