<a href="/blog/owning-your-app-is-good-actually">Recently</a>, I discussed the importance of "owning your app" in the Javascript ecosystem and the problems that stem from relying too heavily on third-party services and dependencies. This post focuses specifically on authentication, if you want an overview of what this series is about, I suggest you read the other article first.
<hr>
Authentication is a beast, arguably the most complex and error-prone part of setting up any app, and a critical aspect of truly owning your app. Fully comprehensive authentication solutions, offered by the likes of Clerk, Auth0, and Supabase, can take care of not just the actual authentication and session management but also provide social logins, password reset functionality (with emails), two-factor authentication (2FA), pre-built UI components and more. When setting up an app it can be temping to reach for one of these instead of handling everything manually in your code, but as your app grows, the real costs can start to surface.
<h2>Third-party authentication services</h2>
One of the biggest risks of coupling your app's authentication with a third-party service is vendor lock-in. Authentication is generally pretty central to how a web app works and if you build your base off the back of a vendor's specific API's and SDKs, it can be incredibly time-consuming, or in some cases practically impossible, to switch to a different provider or migrate to a self-hosted solution. You're essentially at the mercy of the vendor, subject to their pricing changes, feature limitations, and roadmap decisions.
If you're okay with the lock-in, you must also be okay with the pricing. Pretty much all authentication providers offer a free tier which, if you plan on making any money, you will eventually hit the ceiling at which point your free ride begins eating into your margins. This problem can be especially expensive if you have a free tier or if you plan on going B2C.
You're also completely exposed to the provider's maintenance and release cycles. By coupling your app's authentication to their service, you must update your app and its code as their APIs and SDKs develop, which can be pretty time-consuming and stressful if you have a relatively complex app. You're also exposing your users to the provider's their uptime, which in the case of authentication, can mean locking all logged-in users out of your app in the event of an outage.
All of these things combined can become tech debt and hugely hinder your ability to actually deliver features to your customers.
<h2>"Rolling your own auth"</h2>
Given these drawbacks, you might be wondering what the solution is. Enter the concept of "rolling your own auth" - a term that's often misunderstood and, in the JavaScript world, sometimes unfairly maligned.
The term "rolling your own auth" has traditionally been associated with implementing authentication algorithms from scratch in your code, which can be daunting and error-prone, and should be avoided. In modern web development, however, it's been redefined to mean "leveraging battle-tested authentication libraries and frameworks instead of relying on third-party services". This is a problem.
In traditional SSR frameworks like Laravel, Rails, and Django, "rolling your own auth" is not frowned upon and is actually the expected approach. Authentication in deeply integrated at the core of these frameworks and it's generally always the right move to choose these first-party, battle-tested libraries instead of reaching for a third-party service.
The JavaScript ecosystem at large, however, does <a href="https://www.youtube.com/watch?v=yaodD79Q4iE">not generally choose batteries-included frameworks</a>, instead preferring a more modular approach. The result is the authentication libraries grow somewhat separately to the frameworks themselves, spawning the likes of <a href="https://authjs.dev/getting-started/integrations"><code>Auth.js</code></a> (formerly NextAuth) and <a href="https://github.com/sergiodxa/remix-auth"><code>remix-auth</code></a>. Despite the existence of these battle-tested libraries, the concept of "rolling your own auth" in JavaScript still comes with a certain level of apprehension.
Let me be clear: it's not as daunting as you might think, and the benefits are substantial.
Firstly, using an off-the-shelf library allows you to own your users outright in your database. This means that you have total control over your user data and can easily migrate or switch your authentication library over time if you wanted. This is only possible with in-house authentication as the implementation and storage of your authentication are completely decoupled. If you used to use <code>Passport.js</code> and now you want to use <code>Auth.js</code>, it's possible to switch without any downtime. To go even further, you could even rewrite your app using a totally different stack and your users would be unaffected as their user information, password information and even their session information all exists in your database.
Owning the user information in your own database also completely removes the need to worry about Daily Active Users (DAU) or Monthly Active Users (MAU) costs as you are not bound by third-party provider fees. The cost of onboarding a new user to your app from an authentication perspective is, for all intents and purposes, zero.
Authentication libraries have also matured a lot over the years and have long moved past basic login and session management. <code>Auth.js</code> and <code>remix-auth</code> both support social logins (extendable to any OAuth provider), magic links, WebAuthn and 2FA. They also support handling sessions with HTTP-only cookies, rather than Javascript-readable JWTs, which is something that most of the third-party authentication services don't.
<h3>A quick note on JWTs in Localstorage</h3>
Javascript-readable JWTs, usually either in LocalStorage or non-HTTP-only cookies, are broadly deemed less secure than session cookies as they cannot be revoked individually without the use of a centralised table. This means if you need to quickly ban a malicious user, alter a user's permissions due to a role change, or invalidate a compromised token, you would need to wait for the token to expire naturally or force all users to log out and obtain new tokens. Managing sessions with cookies, and querying centralised sessions table on each request, nullifies all of these issues.
<h3>OAuth-only authentication</h3>
If you still don't fancy handling passwords, there's an even simpler approach: OAuth-only authentication. By only supporting OAuth, provided by the likes of Google, GitHub, and Facebook, you eliminate the need to store or manage passwords, removing a significant security risk, while maintaining full control over sessions and user data.
OAuth can also result in a simpler experience for both you (the developer) and your customers. You will end up writing less code as you no longer have to manage passwords and their adjacent functionalities (e.g. resets) and your customers won't have to remember what sign-in method they used when creating their account.
<h2>Risks</h2>
It wouldn't be fair to talk about in-house authentication without talking about the risks. While you aren't exposed to the risk of your third-party provider getting breached, you must still ensure it doesn't happen to you. The libraries I've mentioned will handle most of the application-level logic around implementing the cryptographic algorithms, but it's often on you to make sure you're using the library correctly and also to securely persist the data to your database. Thankfully, there are well-established rules to follow and there's plenty of guides around properly hashing and salting passwords, securely generating and storing encryption keys, and following best practices for database security.
<h2>Wrapping up</h2>
I'm hoping this article has helped dispel some of the myths around "rolling your own auth" and show you that it's not as scary as it may seem.
If you're looking for a starter kit for your next web app and you want first-party authentication, as well as emails, database integrations, payments, storage, and caching - all without any vendor lock-in - please check out <a href="https://www.launchway.dev/">Launchway</a>.
Alternatively if you found this at all interesting, please consider <a href="/#newsletter">signing up for the newsletter</a> or <a href="https://twitter.com/brianbriscoe_">simply following me on Twitter</a> where I rant about things like this often.


[Recently](/blog/owning-your-app-is-good-actually), I discussed the importance of "owning your app" in the Javascript ecosystem and the problems that stem from relying too heavily on third-party services and dependencies. This post focuses specifically on authentication, if you want an overview of what this series is about, I suggest you read the other article first.


____

Authentication is a beast, arguably the most complex and error-prone part of setting up any app, and a critical aspect of truly owning your app. Fully comprehensive authentication solutions, offered by the likes of Clerk, Auth0, and Supabase, can take care of not just the actual authentication and session management but also provide social logins, password reset functionality (with emails), two-factor authentication (2FA), pre-built UI components and more. When setting up an app it can be temping to reach for one of these instead of handling everything manually in your code, but as your app grows, the real costs can start to surface.

## Third-party authentication services


One of the biggest risks of coupling your app's authentication with a third-party service is vendor lock-in. Authentication is generally pretty central to how a web app works and if you build your base off the back of a vendor's specific API's and SDKs, it can be incredibly time-consuming, or in some cases practically impossible, to switch to a different provider or migrate to a self-hosted solution. You're essentially at the mercy of the vendor, subject to their pricing changes, feature limitations, and roadmap decisions.

If you're okay with the lock-in, you must also be okay with the pricing. Pretty much all authentication providers offer a free tier which, if you plan on making any money, you will eventually hit the ceiling at which point your free ride begins eating into your margins. This problem can be especially expensive if you have a free tier or if you plan on going B2C.

You're also completely exposed to the provider's maintenance and release cycles. By coupling your app's authentication to their service, you must update your app and its code as their APIs and SDKs develop, which can be pretty time-consuming and stressful if you have a relatively complex app. You're also exposing your users to the provider's their uptime, which in the case of authentication, can mean locking all logged-in users out of your app in the event of an outage. 

All of these things combined can become tech debt and hugely hinder your ability to actually deliver features to your customers.

## "Rolling your own auth"

Given these drawbacks, you might be wondering what the solution is. Enter the concept of "rolling your own auth" - a term that's often misunderstood and, in the JavaScript world, sometimes unfairly maligned.

The term "rolling your own auth" has traditionally been associated with implementing authentication algorithms from scratch in your code, which can be daunting and error-prone, and **should be avoided**. In modern web development, however, it's been redefined to mean "leveraging battle-tested authentication libraries and frameworks instead of relying on third-party services". This is a problem.

In traditional SSR frameworks like Laravel, Rails, and Django, "rolling your own auth" is not frowned upon and is actually the expected approach. Authentication in deeply integrated at the core of these frameworks and it's generally always the right move to choose these first-party, battle-tested libraries instead of reaching for a third-party service.

The JavaScript ecosystem at large, however, does [not generally choose batteries-included frameworks](https://www.youtube.com/watch?v=yaodD79Q4iE), instead preferring a more modular approach. The result is the authentication libraries grow somewhat separately to the frameworks themselves, spawning the likes of [`Auth.js`](https://authjs.dev/getting-started/integrations) (formerly NextAuth) and [`remix-auth`](https://github.com/sergiodxa/remix-auth). Despite the existence of these battle-tested libraries, the concept of "rolling your own auth" in JavaScript still comes with a certain level of apprehension.

**Let me be clear: it's not as daunting as you might think, and the benefits are substantial.**

Firstly, using an off-the-shelf library allows you to own your users outright in your database. This means that you have total control over your user data and can easily migrate or switch your authentication library over time if you wanted. This is only possible with in-house authentication as **the implementation and storage of  your authentication are completely decoupled**. If you used to use `Passport.js` and now you want to use `Auth.js`, it's possible to switch without any downtime. To go even further, you could even rewrite your app using a totally different stack and your users would be unaffected as their user information, password information and **even their session information** all exists in your database.

Owning the user information in your own database also completely removes the need to worry about Daily Active Users (DAU) or Monthly Active Users (MAU) costs as you are not bound by third-party provider fees. The cost of onboarding a new user to your app from an authentication perspective is, for all intents and purposes, zero.

Authentication libraries have also matured a lot over the years and have long moved past basic login and session management. `Auth.js` and `remix-auth` both support social logins (extendable to any OAuth provider), magic links, WebAuthn and 2FA. They also support handling sessions with HTTP-only cookies, rather than Javascript-readable JWTs, which is something that most of the third-party authentication services don't.

### A quick note on JWTs in Localstorage
Javascript-readable JWTs, usually either in LocalStorage or non-HTTP-only cookies, are broadly deemed less secure than session cookies as they cannot be revoked individually without the use of a centralised table. This means if you need to quickly ban a malicious user, alter a user's permissions due to a role change, or invalidate a compromised token, you would need to wait for the token to expire naturally or force all users to log out and obtain new tokens. Managing sessions with cookies, and querying centralised sessions table on each request, nullifies all of these issues.

### OAuth-only authentication

If you still don't fancy handling passwords, there's an even simpler approach: OAuth-only authentication. By only supporting OAuth, provided by the likes of Google, GitHub, and Facebook, you eliminate the need to store or manage passwords, removing a significant security risk, while maintaining full control over sessions and user data.

OAuth can also result in a simpler experience for both you (the developer) and your customers. You will end up writing less code as you no longer have to manage passwords and their adjacent functionalities (e.g. resets) and your customers won't have to remember what sign-in method they used when creating their account.


## Risks
It wouldn't be fair to talk about in-house authentication without talking about the risks. While you aren't exposed to the risk of your third-party provider getting breached, you must still ensure it doesn't happen to you. The libraries I've mentioned will handle most of the application-level logic around implementing the cryptographic algorithms, but it's often on you to make sure you're using the library correctly and also to securely persist the data to your database. Thankfully, there are well-established rules to follow and there's plenty of guides around properly hashing and salting passwords, securely generating and storing encryption keys, and following best practices for database security.

## Wrapping up

I'm hoping this article has helped dispel some of the myths around "rolling your own auth" and show you that it's not as scary as it may seem. 

If you're looking for a starter kit for your next web app and you want first-party authentication, as well as emails, database integrations, payments, storage, and caching - all without any vendor lock-in - please check out [Launchway](https://www.launchway.dev/).

Alternatively if you found this at all interesting, please consider [signing up for the newsletter](/#newsletter) or [simply following me on Twitter](https://twitter.com/brianbriscoe_) where I rant about things like this often.

A deep dive into the benefits and trade-offs of owning your app's authentication

Owning your app - Part 1: Authentication

The concept of "owning your app" in the Javascript community is a lost art in 2024, and I'm here to explain why it's bad and why it matters
<blockquote>
Ownership: the act, state, or right of possessing something.
</blockquote>
In recent years, there's been a growing trend in Javascript land where, by default, core functionality and infrastructure is offloaded to third-party services and dependencies. Setting up a new project generally involves deeply coupling your database and user management to third-party services, deploying to a proprietary hosting provider, and running an app containing code from tens or hundreds of NPM packages - sometimes even for functionality like <a href="https://www.npmjs.com/package/is-number">checking if a value is a number</a>.
In a sense Javascript is a victim of its own success. Being extremely popular, the space moves fast, arguably too fast, which leaves little breathing room that would allow for standards and winners to emerge like you see in Python with Django or Ruby with Rails. Even if things moved slower, I don't think the community would accept a winner because sooner or later a new shiny thing would come along and become the new state of the art. Long gone are the days of jQuery and MooTools being the "one true way" to write Javascript apps.
The reason I think this is bad is it results in a lack of ownership.
Let me clarify that I am not suggesting that you write all functionality from scratch every time you write an app. Some usage of third-party services, packages and hosting providers are an essential part of writing a Javascript app in 2024 and I think abundance of options in these areas are one of the ecosystem's strengths.
My issue lies with the willingness of the Javascript community, spurred on by VC-backed DevRels and other influencers, to default to reaching for an off-the-shelf solution for functionality that could be easily written and owned within your app code.
Every time you choose to add a dependency for something you could have written yourself, you're making a bet. A bet that the library maintainer won't <a href="https://www.sonatype.com/blog/npm-libraries-colors-and-faker-sabotaged-in-protest-by-their-maintainer-what-to-do-now">sabotage the package</a> you use due to a lack of funding, a bet that your VC-backed database provider won't <a href="https://planetscale.com/docs/concepts/hobby-plan-deprecation-faq">rug-pull their free tier so they can focus on enterprise</a>, a bet that your app hosting provider wont <a href="https://portswigger.net/daily-swig/heroku-resets-user-passwords-after-concluding-april-cyber-attack-ran-deep">get hacked and request you change all of your secrets</a>, or that your auth provider won't ship a <a href="https://dev.to/emmanuelthecoder/recent-security-vulnerability-detected-in-clerk-should-you-roll-your-own-auth-52l1">critical security vulnerability</a>.
By delegating too much ownership to external vendors, you're not only risking security and stability but you also lose the agility to pivot and adapt your app as needed. The end-game of this approach is being so locked into proprietary database features, platform-specific APIs, and third-party dependencies that any significant change can become a major overhaul rather than a manageable update.
The path to regaining control of your Javascript app doesn't mean rejecting all third-party services altogether, rather carefully choosing which parts of your app you should own outright. In the upcoming series, I'll dig deeper into the specifics of owning various parts of your app. Specifically, I'll focus on what I feel are the areas where ownership is the most important
<ul>
<li>Authentication</li>
<li>Infrastructure</li>
<li>Code</li>
</ul>
By taking a critical look at these areas and figuring out where it makes sense to maintain ownership, you can write Javascript applications that are built for the future. If this is something you'd be interested in, please <a href="/#newsletter">sign up for the newsletter</a> or <a href="https://twitter.com/brianbriscoe_">follow me on Twitter</a>



The concept of "owning your app" in the Javascript community is a lost art in 2024, and I'm here to explain why it's bad and why it matters

> Ownership: the act, state, or right of possessing something.

In recent years, there's been a growing trend in Javascript land where, by default, core functionality and infrastructure is offloaded to third-party services and dependencies. Setting up a new project generally involves deeply coupling your database and user management to third-party services, deploying to a proprietary hosting provider, and running an app containing code from tens or hundreds of NPM packages - sometimes even for functionality like [checking if a value is a number](https://www.npmjs.com/package/is-number).

In a sense Javascript is a victim of its own success. Being extremely popular, the space moves fast, arguably too fast, which leaves little breathing room that would allow for standards and winners to emerge like you see in Python with Django or Ruby with Rails. Even if things moved slower, I don't think the community would accept a winner because sooner or later a new shiny thing would come along and become the new state of the art. Long gone are the days of jQuery and MooTools being the "one true way" to write Javascript apps.

The reason I think this is bad is it results in a **lack of ownership**.

Let me clarify that I am **not suggesting that you write all functionality from scratch** every time you write an app. Some usage of third-party services, packages and hosting providers are an essential part of writing a Javascript app in 2024 and I think abundance of options in these areas are one of the ecosystem's strengths.

My issue lies with the willingness of the Javascript community, spurred on by VC-backed DevRels and other influencers, to default to reaching for an off-the-shelf solution for functionality that could be easily written and owned within your app code.

Every time you choose to add a dependency for something you could have written yourself, you're making a bet. A bet that the library maintainer won't [sabotage the package](https://www.sonatype.com/blog/npm-libraries-colors-and-faker-sabotaged-in-protest-by-their-maintainer-what-to-do-now) you use due to a lack of funding, a bet that your VC-backed database provider won't [rug-pull their free tier so they can focus on enterprise](https://planetscale.com/docs/concepts/hobby-plan-deprecation-faq), a bet that your app hosting provider wont [get hacked and request you change all of your secrets](https://portswigger.net/daily-swig/heroku-resets-user-passwords-after-concluding-april-cyber-attack-ran-deep), or that your auth provider won't ship a [critical security vulnerability](https://dev.to/emmanuelthecoder/recent-security-vulnerability-detected-in-clerk-should-you-roll-your-own-auth-52l1).

By delegating too much ownership to external vendors, you're not only risking security and stability but you also lose the agility to pivot and adapt your app as needed. The end-game of this approach is being so locked into proprietary database features, platform-specific APIs, and third-party dependencies that any significant change can become a major overhaul rather than a manageable update.

The path to regaining control of your Javascript app doesn't mean rejecting all third-party services altogether, rather carefully choosing which parts of your app you should own outright. In the upcoming series, I'll dig deeper into the specifics of owning various parts of your app. Specifically, I'll focus on what I feel are the areas where ownership is the most important

- Authentication
- Infrastructure
- Code

By taking a critical look at these areas and figuring out where it makes sense to maintain ownership, you can write Javascript applications that are built for the future. If this is something you'd be interested in, please [sign up for the newsletter](/#newsletter) or [follow me on Twitter](https://twitter.com/brianbriscoe_)


A brief critique on the state of Javascript apps in 2024

Blog