In the past few years, adding authentication to your app has shifted from something obscure and complicated to something for which you can simply use an API.
While there are countless example repositories and tutorials for implementing specific auth schemes in Next.js, there is less content available about the why behind selecting schemes, tools, and tradeoffs.
This post will guide you through the considerations when approaching authentication in Next.js, from choosing a provider to creating routes for sign-in and deciding between server vs. client-side authentication.
Choosing an Authentication Method / Provider
When it comes to integrating authentication into your app, there are numerous ways to go about it. Rather than focusing on specific providers here (which could be the subject of another blog post), let’s examine types of authentication solutions and provide a few examples of each. In terms of implementation, next-auth is emerging as a popular option for integrating your Next.js app with multiple providers and adding SSO, among other features.
Traditional Database
One of the simplest forms of authentication is storing usernames and passwords in a relational database. Traditional database auth schemes are widely used and offer high flexibility, affordability, and independence from specific vendors, but they require custom development and attention to security considerations.
Authentication Solutions From Your Database Provider
Managed database providers like Firebase, Supabase, and AWS offer authentication solutions as part of their services. These solutions abstract user creation and session management, making authentication a more straightforward process. For example, signing a user in with Supabase authentication is as simple as calling a specific function.
Authentication Solutions Not From Your Database Provider
Companies like Auth0 and Stytch provide standalone authentication products that prioritize developer experience and usability. Additionally, single sign-on (SSO) solutions can be outsourced to enterprise vendors like Okta, or widely adopted platforms like Google or GitHub.
Okay, So Which One Is for Me?
There is no one-size-fits-all solution for authentication. Your choice will depend on your project’s priorities and complexity. If you prefer a quick setup with minimal configuration, outsourcing authentication may make sense. However, if you anticipate a more complex setup, building your own authentication system is a viable option.
Building Routes for Sign-Up and Sign-In, and Tips for Going to Extra Authentication Mile
Some authentication providers offer complete web pages for sign-up and sign-in. However, if you are building these pages from scratch, creating their structure early in the process can be beneficial. Additionally, implementing routes for sign-up, sign-in, and handling edge cases like password resets are essential to provide a smooth user experience.
Choosing Between Sessions and JWT
After a user authenticates, deciding between sessions (cookies) and JSON Web Tokens involves balancing server-side and client-side workloads. Session-based authentication involves server logic and work for maintaining authentication, while JWTs primarily handle this on the client side.
Choosing Between Server Side and Client Side Auth
Next.js offers the flexibility to render static loading pages and fetch user authentication details on the client side or handle authentication server-side using the `getServerSideProps` function.
Summary
When selecting an authentication approach, consider your confidence in the speed of your authentication scheme. If requests are fast, you can run them server-side. However, if you want to prioritize rendering an initial response quickly, without waiting for the server, client-side authentication could be a suitable option.
