If you’re a small to medium business building out a digital platform or a startup you need authentication – a way to register new users and handle verifying existing users.
Unless your product is “user authentication” this is not something we would recommend you build yourself. Resist the DIY urge, ignore the call of “Not Invented Here”, and actively shutdown the hubris of “the spec isn’t that complicated and there are plenty of reference implementations”.
The biggest argument for this is simple – user authentication is basic “product hygiene”. It’s one of the fundamental features every app and website needs to have and it is one of the features of your product your users will expect. And It has nothing to do with your Unique Value Proposition or whatever moat you are trying to build. So you shouldn’t be wasting time, money or innovation on user authentication. Spend your precious resources on building value and wire up someone else’s API to do the authentication for you.
There is a secondary argument if you are in industries with strict regulatory requirements, like fintech or health, or you want to sell to enterprise – compliance is hard. Hard means expensive and time consuming. It probably requires audits. Your potential clients would rather see a proven solution in place that lets them tick their own compliance boxes. Make it easy for them and yourself – use the API of the proven solution.
The Pros and Cons of Authentication As A Service
There’s really only one Pro of using an authentication provider – you don’t have to write the code yourself. That takes a lot of effort and responsibility off your plate once you make the decision, and it eliminates all kinds of ongoing management burdens. When your lean startup team is racing to revolutionise the property market you don’t want to lose anyone to diagnosing why password reset emails are being delayed by 2 hours and ending up in spam folders.
Instead you can let your authentication provider’s team of 40-50 developers worry about that for you. They’ve been doing it for years.
And over the years they’ve implemented things like social sign-on for Google, Apple, Facebook, Github, etc, and 2 Factor Authentication and password recovery and all the features you need to make it as easy as possible for your users to authenticate and use your product.
Now, there are several cons. Some see the biggest con as having to pay for the service. Maybe do some math around what you might be paying your developers to build an authentication system plus what you would be paying for the ongoing management of it (particularly the security side of things), add in how much it would cost you to get it wrong, and use those numbers to guide your decision.
The next biggest con, or concern, is vendor lock-in. Providers do offer a path for migrating away from their service, but often the lock-in comes in the form of deep integration of the service into your code base.
There are ways to mitigate this implementation-based lock-in and they are also basic good software practices. Your developers are going to be writing code that calls the provider’s API either directly or via an SDK (Software Development Kit). They can write a more generic interface to “authentication services” which allows you to swap out providers or eventually swap in your own. It’s a little more effort in the beginning, but not much more than a direct implementation for a specific provider, and it enables you to leave your options open.
Also, make sure you own any custom domains that are used as part of the authentication flow. Some users bookmark login pages, and some authentication standards use hostnames as part of their configuration (they need to know for sure where they are sending users and data). You don’t want to lose them if you change providers.
Why have authentication at all – the Magic Link
If your product is B2C and doesn’t need to secure sensitive information or payment details (because you’ve offloaded that to a service like Stripe) you may be wondering if you need authentication at all.
A current pattern that is comparatively minimalist in implementation (beyond having some solid email infrastructure or a trustworthy email provider who’ll keep you out of spam folders) is the Magic Link.
What is the Magic Link pattern?
The Magic Link pattern is where a product doesn’t ask you to register but asks for an email address and sends an email with an access link.
This offloads authentication to email providers like Google and Microsoft (who are very good at that) and it also helps eliminate account sharing. Anthropic use this pattern to good effect.
On the backend an account is still created in a database somewhere and the email address is the central identifier. On the browser or app side session tokens are stored and if the user has to do anything important – like pay you, change important settings – you send them another Magic Link.
Technically, it is simple to implement. Much simpler than login flows, social sign-ons, password recovery, 2FA, etc. Many users don’t like this system and the switching between applications it requires. It is not the best UX, especially on mobile. But for your product and your users it might be enough.
Who are the Authentication As A Service providers?
Here is a comparison table of the major AaaS options as of late 2024. Note that it includes KeyCloak, which is open source and self-hosted, and SuperTokens, which offers a self-hosted option. This is because we’re being thorough and they are technically not “DIY”, but both come with the burden of management. But if you need the control, you need the control.
Try not to need the control if you haven’t launched yet.
| Service Name | Overview | Pricing Model | Key Features | Integration Complexity | Scalability | Compliance & Certifications | Customization & Control | Social Logins Supported |
|---|---|---|---|---|---|---|---|---|
| Auth0 | Comprehensive authentication platform suitable for businesses of all sizes. | Free tier available; paid plans based on Monthly Active Users (MAUs) and features. | Supports SSO, MFA, social logins; extensive compliance standards. | Moderate; well-documented but may require setup time. | High; designed for large-scale applications. | GDPR, HIPAA, SOC 2, ISO 27001, and more. | High; customizable authentication flows and branding. | Yes (Google, Facebook, Twitter, Microsoft, LinkedIn, GitHub, Apple, and more) |
| Firebase Auth | Authentication service by Google as part of the Firebase platform. | Generous free tier; pay-as-you-go pricing for additional usage. | Email/password, phone auth, social logins; tight integration with Firebase services. | Easy; straightforward, especially within Firebase ecosystem. | High; backed by Google’s infrastructure. | Complies with Google’s security standards. | Limited; less flexibility in customizing flows. | Yes (Google, Facebook, Twitter, GitHub, Apple, Microsoft, Yahoo, Play Games, and more) |
| Clerk | Modern authentication with a focus on developer experience and user interface. | Free for up to 10,000 MAUs; paid plans for higher usage and features. | Magic links, social logins, MFA; pre-built UI components. | Easy; developer-friendly SDKs for popular frameworks. | Scales with your user base; costs increase with usage. | SOC 2 Type 2, CCPA compliant. | High; customizable components and APIs. | Yes (20+ providers including Google, Facebook, Twitter, GitHub, Apple, Microsoft, LinkedIn, Slack, Discord, and more) |
| Supabase Auth | Open-source alternative to Firebase, integrating seamlessly with PostgreSQL databases. | Free tier; affordable paid plans for additional resources. | Email/password, magic links, social logins; works with Supabase services. | Easy; especially if using the Supabase stack. | Moderate to high; depends on your infrastructure. | Self-managed compliance; open-source transparency. | Moderate; customization possible with development effort. | Yes (Google, Facebook, Twitter, GitHub, GitLab, Bitbucket, Apple, Azure, LinkedIn, Twitch, Discord, Slack, Spotify, Notion, and more) |
| FusionAuth | Customer identity platform offering a free community edition and paid enterprise options. | Free community edition; paid plans for enterprise features and support. | OAuth2, OIDC, SAML support; self-hosting for full control. | Moderate; requires setup but provides good documentation. | High; built to handle millions of users. | GDPR, CCPA, HIPAA (with enterprise edition). | High; extensive customization when self-hosted. | Yes (Google, Facebook, Twitter, LinkedIn, GitHub, Apple, Amazon, Steam, and others) |
| AWS Cognito | Amazon’s solution for user sign-up, sign-in, and access control. | Free tier; pay-as-you-go based on MAUs and features used. | Email/password, social logins, MFA; integrates with AWS services. | Complex; may require AWS expertise. | High; scalable on AWS infrastructure. | HIPAA eligible; aligns with AWS compliance programs. | Moderate; customization possible but complex. | Yes (Google, Facebook, Amazon, Apple, and any OpenID Connect or SAML 2.0 identity provider) |
| SuperTokens | Open-source authentication focusing on security and user experience. | Core features are free; paid for managed services and enterprise features. | Email/password, social logins, passwordless; self-hosting option. | Moderate; developer-friendly but requires setup. | High; scalable when self-hosted. | Self-managed compliance responsibilities. | High; full control with open-source code. | Yes (Google, Facebook, Apple, GitHub; extendable with custom providers) |
| Keycloak | Open-source identity and access management solution for enterprise applications. | Free; fully open-source and self-hosted. | SSO, social login, identity brokering; extensive features. | Complex; requires technical expertise to deploy and maintain. | High; depends on your hosting infrastructure. | Self-managed; compliance depends on your setup. | Very high; highly customizable but complex. | Yes (Supports any OpenID Connect or SAML 2.0 providers, including Google, Facebook, Twitter, GitHub, LinkedIn, Microsoft, and more) |
Go build value, not login flows
If you reached this point we hope you understand the big picture when it comes to user authentication and how to get it done. It’s a complicated topic and only you know what your requirements are. Between our basic advice and that table of AaaS service providers up there we hope we gave you a good start on narrowing down your decision on who to go with.
If you need more details or want to talk more about building out a digital platform on modern standards we love talking about this stuff. Get in touch.
