Why sign-in matters for conversion, and where Medusa falls short
Medusa has become the reference open-source commerce engine for custom stores, and its business case is easy to sum up. You own the code, no commission is added to your sales, and the platform adapts to your business rather than the other way round. We covered this comparison in detail in our article Shopify vs Medusa.
When it comes to authentication, however, Medusa v2 deliberately sticks to the minimum, which is sign-in with an email and a password. It offers no Google or Apple sign-in, no magic links sent by email that log you in with one click, and no passkeys using a fingerprint or face recognition. This is a deliberate design choice, since Medusa focuses on commerce and leaves advanced authentication to specialised tools. The gap is real nonetheless, and it is paid for twice, in accounts that never get created on the store side, and in custom development on the project side, rebuilt each time in one of the areas where hand-rolled code carries the most risk.
What we built
To close this gap, we developed an open-source plugin that connects Medusa v2 to Better Auth, the reference authentication library in the TypeScript ecosystem. It grew out of a real e-commerce project we are preparing for production. It is published under the MIT licence on npm, listed in the Medusa plugin ecosystem, and other developers have already adopted it in their own stores.
In practice, the plugin brings the following to any Medusa v2 store.
- Social sign-in through eight providers, Google, Apple, Facebook, Microsoft, Discord, TikTok, X and GitHub, each enabled with two environment variables, with buttons and icons included.
- Magic links, passkeys and two-factor authentication, through the Better Auth plugin ecosystem.
- A sign-in widget for the admin dashboard, with the social buttons above the standard form.
- An idempotent migration command for production deployments, which can be run safely at every release.
- Normalisation of customer emails, so that duplicate accounts cannot occur.
Above all, it brings all of this without breaking anything, and that architectural choice shaped everything else.
A bridge alongside Medusa's own authentication
The plugin complements Medusa's authentication and leaves it in place. Better Auth runs inside the Medusa server, with its tables stored in the same Postgres database under the ba_ prefix. It handles the modern sign-in flow, after which a dedicated Medusa authentication provider validates the session and lets Medusa issue its own native token, either a customer token or an admin token. The storefront, the admin and protected routes keep working with Medusa's standard authentication, without a single line changed. The native model remains the source of truth.
Another consequence of this choice is that there is no ongoing performance cost. Better Auth only comes into play at sign-in. After that, customers browse with their native Medusa token, and the plugin steps out of the way.
A locked-down admin
A social sign-in can never create an admin account. A Google identity can only be linked to an existing administrator, invited in the usual way in Medusa, and only if the provider has verified the email address. Without this strict rule, a misconfigured social login would become a way into the back office of the store. We made it non-negotiable.
No duplicate customer accounts
Without a safeguard, a customer who types their email with a capital letter one day and in lowercase the next ends up with two separate accounts, which splits their order history, confuses support and skews the statistics. The plugin normalises emails at the source, while respecting the way Medusa keeps guest orders separate from customer accounts. Nothing is merged automatically on the basis of an email alone, and linking goes through Medusa's order transfer flow, which requires proof that the customer owns the mailbox.
Built for production, documented with its limits
The plugin's documentation covers what usually breaks a launch, such as rate limiting, which must move to shared storage behind a load balancer, cookies to configure between the store domain and the API domain, periodic cleanup of expired sessions and monitoring of Postgres connections. It is also open about the known limits, including the versions verified, edge cases depending on the package manager, and points still in progress. An authentication component that hides its limits is a component nobody can trust.
What this changes for an e-commerce project
The equation works on two levels. Medusa, first, gives you a store whose code you own, with no commission taken on your sales, and which reproduces your business rules instead of imposing its own. This plugin, second, removes what was one of the real reservations compared with turnkey platforms. Modern sign-in, the kind that reduces signup friction and protects conversion, no longer needs to be built on your budget. It becomes an existing component to install, with its production pitfalls already identified and handled. The convenience gap with a proprietary solution closes, while the structural advantages of open source remain.
At Nualt, this is how we work. We build our stores on Medusa, and when a piece is missing, we make it properly and give it back to the ecosystem instead of keeping it in a drawer. That other developers have read the code and chosen to install it is the most honest validation there is.
Frequently asked questions about Medusa authentication and the plugin
The questions that come up most often about authentication in Medusa v2 and about what the plugin covers, with short answers. For the full technical detail, the plugin's documentation on GitHub remains the reference.
Does Medusa v2 support Google login or magic links natively?
No. The native module covers sign-in with an email and a password. Social login, magic links, passkeys and two-factor authentication require a complementary tool such as Better Auth, connected to Medusa through a dedicated connector, which is precisely what this plugin provides.
What exactly does our plugin include?
Social sign-in through eight providers configurable with environment variables, magic links, passkeys and 2FA through Better Auth, a sign-in widget for the admin, a migration command for production and normalisation of customer emails. All of this works without modifying Medusa's native session model.
Do you need to replace Medusa's authentication to use it?
No, and this is the core of its architecture. Better Auth handles the sign-in, then Medusa issues its own native token. The storefront, the admin and protected routes keep working without any change.
Can a social login create an admin account?
Never. A social identity can only be linked to an administrator already invited in Medusa, and only if the provider has verified the email address. This security rule is deliberately non-negotiable.
Why choose Medusa for e-commerce if modern authentication is not built in?
Because Medusa's structural advantages remain intact, with full ownership of the code, no commission on sales and complete freedom over business rules. Modern authentication was one of the convenience gaps compared with turnkey platforms, and this plugin closes it. The choice of platform rests on its foundations, and a feature that can be added should not decide it.
