We've just shipped a major upgrade to how authentication works on the Badger Commerce platform. Instead of every store maintaining its own user database and login flow, we've built a central authentication server that provides a single, secure identity layer across all your sites.
Here's what's new and why it matters.
One account, every store
Previously, each Badger Commerce store had its own user accounts. If a customer shopped on two different stores powered by the platform, they needed separate accounts for each.
Now, authentication is handled centrally via OpenID Connect (OIDC). A customer creates one account and can use it across any store that opts in. The central auth server issues tokens, and each store validates them — no passwords are shared between systems, and no customer data leaks across tenants.
From the customer's perspective, they see a polished, branded login page that matches the store they came from, but behind the scenes it's the same secure identity.
Passkeys: the future of sign-in
We're big believers in the passwordless future, and passkeys are our recommended sign-in method. Powered by the WebAuthn standard and built on Spring Security's native passkey support, customers can now register and authenticate using:
- Fingerprint (Touch ID, Windows Hello)
- Face recognition (Face ID)
- Device PIN as a fallback
Passkeys are phishing-resistant — there's nothing to type, nothing to remember, and nothing that can be stolen in a data breach. They're also significantly faster than passwords. We've made passkeys the recommended option on the registration page, with a clear "Recommended" badge to nudge adoption.
How it works under the hood
The auth server uses Spring Security 6.4's WebAuthn configurer with a MongoDB-backed credential repository. When a customer registers a passkey:
- The browser calls
navigator.credentials.create()to generate a public/private key pair - The private key stays on the device (never leaves)
- The public key is stored server-side, linked to the customer's identity
- On future logins, the server sends a challenge, the device signs it, and we verify the signature
The entire ceremony happens inline on the registration page — no redirects, no extra clicks. If the customer cancels the biometric prompt, they're redirected to their account page where they can set up an alternative method.
Social login: Google & Apple
For customers who prefer it, we support Sign in with Google and Sign in with Apple. These use standard OAuth2/OIDC flows and are fully integrated with the central identity system.
When a customer signs in with Google for the first time, we create a central identity and link the Google account to it. They can later add a passkey, set a password, or connect Apple — all from the account management page. One identity, multiple ways to authenticate.
Social accounts are configured per-deployment, so you can enable Google, Apple, both, or neither depending on your audience.
Magic links: passwordless email
Not everyone has a device that supports passkeys, and some customers just prefer email. Magic links let customers sign in with a single click from their inbox — no password required.
The flow is simple:
- Enter your email on the login page
- Receive an email with a secure, time-limited link
- Click the link and you're in
Magic links are also available as a registration method, so new customers can create an account without ever setting a password.
The account management portal
Every customer gets access to a central account page where they can manage their identity across all connected stores. From here they can:
- Update their display name (synced to stores on next login)
- Set or change a password (even if they originally registered with a passkey or social login)
- Add or remove passkeys (multiple passkeys supported for different devices)
- Link or unlink social accounts (Google, Apple)
- See which stores they're connected to with direct links back to each one
The account page includes a clear warning if no sign-in method is configured, ensuring customers don't accidentally lock themselves out.
Smart step-up authentication
When a store needs to re-verify a customer's identity — for example, when their session has expired — the auth server uses encrypted login hints to streamline the experience. Instead of showing a generic login form, the server:
- Recognises who the customer is from the OIDC request
- Shows their email and available auth methods
- If they have a passkey, auto-triggers the biometric prompt — one tap and they're back in
This reduces the friction of re-authentication from "type your email and password" to "touch your fingerprint sensor."
Post-checkout account creation
One of the most impactful features for conversion: anonymous customers can now create an account after placing an order. On the order confirmation page, we show a non-intrusive "Save your details for next time" prompt.
For stores using central auth, this takes the customer through the full OIDC flow with passkey, social login, or password options. For stores with local auth, it's an inline registration form. Either way, the existing order stays linked to the new account — no history is lost.
Embeddable profile widget
Stores can embed a lightweight profile widget via an iframe that shows the customer's authentication status, display name, Gravatar, and connected social accounts. This lets stores surface account information without building their own profile UI.
The widget communicates securely via HMAC-signed embed tokens and respects the store's Content Security Policy.
What's next
This is the foundation for a lot more to come:
- Multi-factor authentication (TOTP, SMS) for high-security stores
- Account linking across tenants (consolidate identities)
- Delegated admin access (manage customer accounts from the store admin)
- Passkey-first checkout for returning customers
Central authentication is available now on the development environment and will roll out to production shortly. If you're running a Badger Commerce store and want to enable it, reach out — we'd love to help you get set up.
Built with Spring Authorization Server, Spring Security WebAuthn, and WebAuthn4j. Running on our k3s cluster, deployed via Flux CD.
