DEV Community: Userfront

Security-charging Your NextJS 14 App with Userfront Authentication

Userfront Devs — Wed, 24 Jul 2024 19:21:26 +0000

As we build increasingly complex applications with NextJS 14, it's crucial to implement authentication and authorization correctly. Developers know that Identity Management and Authentication (IAM) is a revenue driver. Users need easy security they can place confidence in, and companies need organizational architectures and compliance.

Are you looking for a modern, easy-to-implement IAM that supports NextJS 14 application design and best practices? This article guides you through integrating Userfront authentication into your NextJS 14 app, focusing on security best practices.

We'll start by covering the basics of Userfront integration, but our main goal is to dive deep into the implementation of a secure, production-ready authentication system. We explore:

Client-side authentication flows using Userfront's components
Secure routing and protected layouts in NextJS 14
Implementing server-side verification for sensitive data access, ensuring authorization checks are performed close to the data source

Throughout, we emphasize the separation of concerns between client and server, the importance of server-side validation, and the proper handling of JWTs.

Let's begin by setting up Userfront in a NextJS 14 project, and then we'll progressively build out our secure authentication infrastructure.

Get started with Userfront for NextJS 14

The Userfront Next SDK integrates seamlessly with NextJS, allowing developers to implement secure authentication quickly and efficiently. Userfront provides a comprehensive solution for adding authentication to your NextJS 14 application. It offers:

A generous free tier with a user data source prepopulated
Plug-and-play components
A range of sign-on methods from emails to SSO
Custom JWTs for the fields you want to capture
Multi-tenancy

Here are four essential resources to get you started with Userfront in your NextJS 14 project:

@userfront/next package on npm provides a set of components and hooks that make it easy to add authentication to your Next.js app.
Quick Start guide walks you through the basics of setting up Userfront in your project, including:
- Installing the Userfront Next.js library
- Adding the Userfront provider to your layout
- Creating login, signup, and dashboard pages
Userfront Next.js Guide is a more in-depth look at integrating Userfront with Next.js. This guide covers:
- Installation and setup
- Using the UserfrontProvider
- Client-side components and hooks
- Server-side methods and authentication
Userfront NextJS 14 example on GitHub is a fully functional authentication setup using Userfront in a NextJS 14 application.

Build on the Userfront NextJS 14 example

Now that we've covered the basics, let's dive into some best practices for using Userfront with NextJS 14. We'll focus on understanding NextJS 14's design principles and how to keep sensitive data secure to ensure that:

Only requests with valid JWTs can access the protected data
The server verifies the user's identity before returning any sensitive information
The client-side component (UserDataComponent) can't access this data without a valid token

Set up the project

First, make sure you have a Next.js 14 project set up with Userfront installed. If you haven't done this yet, you can grab the example from GitHub by downloading the folder. For example, you can go to download-directory and enter the NextJS project: https://github.com/userfront/examples/tree/main/next-14.

Open the project up and install it with:
npm install

Run the example:
npm run dev

Next, we’ll add a header that changes based on the user login state, a secured router, and a dashboard page that fetches user data if the JWT is verified.

Create a Header component

Let's start by creating a header component that changes based on the user's authentication status:

// app/_components/Header.tsx
"use client";

import Link from 'next/link';
import { useUserfront } from "@userfront/next/client";

export default function Header() {
  const { isAuthenticated, logout } = useUserfront();

  return (
    <header className="p-4">
      <nav className="flex justify-between items-center">
        <Link href="/" className="text-lg font-bold">My App</Link>
        <div>
          {isAuthenticated ? (
            <>
              <Link href="/dashboard" className="mr-4">Dashboard</Link>
              <button onClick={() => logout({ redirect: '/' })} className="bg-blue-500 text-white px-4 py-2 rounded">Logout</button>
            </>
          ) : (
            <>
              <Link href="/login" className="mr-4">Login</Link>
              <Link href="/signup" className="mr-4">Signup</Link>
            </>
          )}
        </div>
      </nav>
    </header>
  );
}

This header component uses the useUserfront hook to determine if the user is authenticated and displays appropriate navigation links.

Then, we’ll update the app layout to include that header. Replace the contents of app/layout.tsx with the following code:

import type { Metadata } from "next";
import { Inter } from "next/font/google";
import "./globals.css";
import { UserfrontProvider } from "@userfront/next/client";

import Header from './_components/Header';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body className="flex justify-center">
        <div className="w-full max-w-5xl px-4 pt-8">
        <UserfrontProvider tenantId={process.env.NEXT_PUBLIC_USERFRONT_TENANT_ID!}>
          <Header />
          {children}
        </UserfrontProvider>
        </div>
      </body>
    </html>
  );
}

Secure routes with layout

Next, let's create a secure layout that protects our dashboard and other sensitive pages. Secure layouts provide a client-side redirect for unauthenticated users, but remember that true security should be implemented server-side.

// app/(secure)/layout.tsx
"use client";

import * as React from "react";
import { useRouter } from "next/navigation";
import { useUserfront } from "@userfront/next/client";

export default function SecureLayout({ children }: { children: React.ReactNode }) {
  const router = useRouter();
  const { isAuthenticated, isLoading } = useUserfront();

  React.useEffect(() => {
    if (isAuthenticated || isLoading || !router) return;
    router.push("/login");
  }, [isAuthenticated, isLoading, router]);

  if (!isAuthenticated || isLoading) {
    return null;
  }

  return children;
}

This layout ensures that only authenticated users can access the pages within the (secure) folder.

Fetch Userfront data as server-side call

To fetch data on the server, we’ll call the UserfrontClient along with the Userfront Admin API key and Tenant ID, which are found in the dashboard.

"use server";


import { UserfrontClient } from "@userfront/next/server";
import Image from "next/image";


// Initialize the Userfront client
const Userfront = new UserfrontClient({
 apiKey: process.env.USERFRONT_API_KEY,
 tenantId: process.env.NEXT_PUBLIC_USERFRONT_TENANT_ID,
});


export default async function ServerPage() {
 try {
   // Get the tenant information
   const tenant = await Userfront.getTenant(process.env.NEXT_PUBLIC_USERFRONT_TENANT_ID);


   return (
     <div  className="container">
       <h1>Server Example with Data Fetching</h1>


       {tenant.image && (
         <div style={{ marginBottom: '20px' }}>
           <Image
             src={tenant.image}
             alt="Tenant Image"
             width={100}
             height={100}
           />
         </div>
       )}


       <h2>Tenant Information:</h2>
       <pre>{JSON.stringify(tenant, null, 2)}</pre>
     </div>
   );
 } catch (error) {
   console.error("Error fetching tenant:", error);
   return (
     <div>
       <h1>Server Example with Data Fetching</h1>
       <p>Error: Unable to fetch tenant information</p>
     </div>
   );
 }
}

We’ll also add Cloudinary as an image in the root next.config.mjs file:


/** @type {import('next').NextConfig} */
const nextConfig = {
   images: {
       domains: ['res.cloudinary.com'],
     },   
};


export default nextConfig;

Now if you run the app, login, and go to the Dashboard, the link Server Example with Data Fetching takes you to a page that displays administrative data about the tenancy.

This is admin data. Dashboards usually display user data, but should do so only if the user’s JWT token has been verified. Next, we’ll create:

A protected route that verifies the user before exposing the component
A UserDataComponent that relies on that protected route
An updated dashboard that displays the UserDataComponent

Implement a protected API route

This protected API route implements server-side JWT verification, which is crucial for securing server-side data access. We’ll need the jsonwebtoken package to verify the access token:
npm install jsonwebtoken

To securely handle sensitive user data, we'll create a new app/api/protected-route/route.ts file that is a protected API route when the JWT token is verified:

// app/api/protected-route/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { UserfrontClient } from "@userfront/next/server";
import jwt, { JwtPayload } from 'jsonwebtoken'; // requires install of this package

const userfront = new UserfrontClient({
  tenantId: process.env.NEXT_PUBLIC_USERFRONT_TENANT_ID!,
});

const JWT_PUBLIC_KEY = process.env.USERFRONT_JWT_PUBLIC_KEY!;

interface UserFrontJwtPayload extends JwtPayload {
  userId?: string;
}

export async function GET(request: NextRequest) {
  try {
    const authHeader = request.headers.get('authorization');
    if (!authHeader) {
      return NextResponse.json({ error: 'No authorization header' }, { status: 401 });
    }

    const token = authHeader.split(' ')[1];

    // Verify the JWT
    const decoded = jwt.verify(token, JWT_PUBLIC_KEY, { algorithms: ['RS256'] }) as UserFrontJwtPayload;

    if (typeof decoded === 'string' || !decoded.userId) {
      throw new Error('Invalid token payload');
    }

    const userId = decoded.userId;

    // Fetch additional user data if needed
    const userData = await userfront.getUser(userId);

    return NextResponse.json({ userData });
  } catch (error) {
    console.error('Authentication error:', error);
    return NextResponse.json({ error: 'Authentication failed' }, { status: 401 });
  }
}

Fetch sensitive user Data

UserDataComponent demonstrates client-side API calls with authentication tokens, aligning with the 'HTTP APIs' approach. However, it relies on proper server-side implementation for actual security. For fetching sensitive user data, we'll create a separate component that makes an authenticated API call. Create a new app/(secure)/dashboard/UserDataComponent.tsx file with the following code:

// app/(secure)/dashboard/UserDataComponent.tsx
'use client';

import { useState, useEffect } from 'react';
import { useUserfront } from "@userfront/next/client";

interface UserData {
  userId: string;
  email: string;
  username?: string;
}

export default function UserDataComponent() {
  const [userData, setUserData] = useState<UserData | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);
  const userfront = useUserfront();

  useEffect(() => {
    async function fetchUserData() {
      const accessToken = userfront.accessToken();
      if (!accessToken) {
        setLoading(false);
        setError('Not authenticated');
        return;
      }

      try {
        const response = await fetch('/api/protected-route', {
          headers: {
            'Authorization': `Bearer ${accessToken}`,
          },
        });

        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }

        const data = await response.json();
        setUserData(data.userData);
      } catch (err) {
        setError(`Error fetching user data: ${err instanceof Error ? err.message : String(err)}`);
      } finally {
        setLoading(false);
      }
    }

    fetchUserData();
  }, [userfront]);

  if (loading) return <div>Loading additional user data...</div>;
  if (error) return <div>Error loading additional data: {error}</div>;
  if (!userData) return <div>No additional user data available</div>;

  return (
    <div className="mt-4">
      <h2 className="text-xl font-semibold">Additional User Information</h2>
      <p>User ID: {userData.userId}</p>
      <p>Username: {userData.username}</p>
    </div>
  );
}

Update the dashboard with the user data component

Now, let's update the dashboard page to display user information. This dashboard component uses client-side data from Userfront, but doesn't inherently provide security. It should be used in conjunction with server-side protections.

// app/(secure)/dashboard/page.tsx
"use client";

import * as React from "react";
import { useUserfront } from "@userfront/next/client";
import UserDataComponent from './UserDataComponent';

export default function DashboardPage() {
  const { user } = useUserfront();

  return (
    <div className="container mx-auto p-4">
      <h1 className="text-2xl font-bold mb-4">Dashboard</h1>
      <p>Hello, {user.email}</p>
      <UserDataComponent />
     <LogoutButton />
     <Link href="/server">Server Example with Async Data Fetching &#8594;</Link>
    </div>
  );
}

Security-charged component

Now you have server-side JWT verification in the protected API route that provides the necessary security for the UserDataComponent. Here's why:

Token Verification: The API route verifies the JWT using the Userfront JWT public key, ensuring the token is valid and hasn't been tampered with.
User Authentication: After verifying the token, it extracts the userId from the decoded token payload, confirming the user's identity.
Authorization: While not explicitly shown in our example, the userfront.getUser(userId) call could be used to fetch user-specific data.
Data Protection: Only after successful verification and potential authorization does the route return user data.

However, it's worth noting:

The security of this system relies on proper management of the JWT public key and other environment variables.
Additional authorization checks might be necessary depending on the specific requirements of your application (e.g., checking user roles or permissions).
While this setup provides good security, always remember that security is a multi-layered concern. This should be part of a comprehensive security strategy including secure coding practices, regular audits, and following the principle of least privilege.

Conclusion

By following these steps and best practices, you can create a secure, authenticated Next.js 14 application using Userfront. Remember to always verify JWTs on the server-side before granting access to sensitive data or protected routes.

Some key takeaways:

Use the UserfrontProvider to wrap your application and provide authentication context.
Implement protected layouts to secure entire sections of your app.
Always verify JWTs on the server-side before returning sensitive data.
Use tools like environment variables to store sensitive information like API keys and JWT public keys and exclude them from check-ins.
Take advantage of Next.js 14's built-in API routes for server-side operations.

By understanding and implementing these concepts, you'll be well on your way to creating secure, scalable Next.js applications with Userfront authentication.

When has rolling your own auth gone wrong?

Userfront Devs — Mon, 01 Jul 2024 15:20:45 +0000

This week we're thinking about what happens when rolling your own auth snowballs into a giant headache. Tell us your own story in the comments!

For a lot of us, this probably feels familiar: everything starts out simple. Add a little home-grown password-based authentication into your app and it seems great - everything just works! But then your app grows, your userbase grows, and your needs get more complicated: suddenly that simple DIY auth solution doesn't do everything you need. Where do you go from there? Do you keep building on top on your existing auth, or do you have to start from scratch with a third-party solution? Are the sunk costs too high to change course, or is the trade-off worth it? And what do you do with all those existing users?

As devs we've been there ourselves. Check out this cautionary tale from Steve Cattaneo, Userfront's Head of Engineering:

Once upon a time, Steve worked at a company that was a Rails shop. Their first product leveraged out-of-the-box Rails password authentication. When they built their second product, for speed to market reasons, much of the boilerplate from the first product was copied into the second product—including the authentication. There was a lot to do and not much time to do it.

Fast forward a few years and Steve’s team built their third product. That, too, included the boilerplate password auth. It was, after all, a simple, straightforward solution that worked.

...then a customer asked for Google authentication, and that's when things started to get complicated.

Steve's team assigned the work to one of the engineers: create an OAuth 2 module. Then migrate users: transition the username-password user to the username backed by a Google identity. He figured it out. He wired it up. And they rolled it out.

Two or three weeks later, that engineer went on a much-deserved vacation. On that Friday — of course — the customer reported issues. Users were unable to log in. Without the engineer who had built the system, they spent the day looking at the code, looking at the database... but couldn't figure it out. The core data pipeline product was fine, but users couldn’t access their dashboard for three days—not counting the weekend.

Eventually they gave their customer a status update: “We’ll have to get back to you.”

(read the rest of the story & find out what happened to Steve's team here!)

Getting started with Passwordless Authentication

Userfront Devs — Fri, 28 Jun 2024 16:02:44 +0000

Passwordless authentication is an alternative to traditional password-based authentication that is gaining traction among organizations aiming to bolster their security infrastructure while enhancing user experience. This article explores the concept of passwordless authentication, its benefits for organizations, various methods, and how to implement passwordless authentication with Userfront.

Definition of Passwordless Authentication

Passwordless authentication refers to the verification of a user's identity without requiring the user to enter a password. This method leverages other forms of identification like single-use codes or security keys, providing a more secure and user-friendly login experience. By eliminating the need for passwords, this authentication method mitigates common password-related security risks.

Benefits of Passwordless Authentication for Organizations

The primary benefits of passwordless authentication boil down to three areas: security, user experience, and operational efficiency.

Security:

Mitigation of Weak or Reused Password Risks: Traditional password-based systems often suffer from weak or reused passwords, making them easy targets for cyber attackers. Passwordless Authentication eliminates this risk, offering a more secure alternative.
Reduced Phishing Attacks: Phishing attempts often target password credentials. By eliminating passwords, the chances of successful phishing attacks are significantly reduced.

User Experience:

Simplified Login Process: Passwordless Authentication simplifies the login process by reducing the steps required to verify a user’s identity.
Elimination of Password Memorization and Resets: Users no longer need to remember or reset passwords, which enhances the overall user experience and reduces frustration.

Operational Efficiency:

Reduced Password-related Support: Organizations often dedicate resources to handle password resets and related support issues. Passwordless authentication lowers the demand for such support.
Lower Operational Costs: By reducing the need for password-related support, organizations can lower operational costs and reallocate resources to other critical areas.

Types of Passwordless Authentication

Verification Codes: Users can opt for a verification code (sometimes called a time-based one-time password or TOTP) sent to their email or SMS address. They then enter this one-time verification code instead of a password.
Magic Links: Much like a verification code, except instead of a code, the user receives a link that they click on to authenticate. Magic links usually have an expiration date and can only be used once.
TOTP Applications: This authentication method allows users to use a TOTP application on their smartphone to verify their identity. TOTP authentication is primarily used as a second factor in MFA signup flows because users must authenticate with the TOTP application through other factors.
Security Keys: Security keys are physical devices that store cryptographic keys to authenticate users. These keys can be connected via USB, Bluetooth, NFC, or even embedded within devices.
Biometrics: Biometric authentication utilizes unique biological traits such as fingerprints or facial recognition to verify a user’s identity.
Single Sign On: SSO could be viewed as a form of passwordless authentication because once a user is verified with an SSO provider, they don’t need to enter an additional password to log in to additional applications.

Implementing Passwordless Authentication with Userfront

Userfront supports the following methods of passwordless authentication:

Magic links
Email verification
SMS verification
TOTP applications
SSO

Here is how you can enable passwordless authentication methods in minutes:

In your Userfront account, navigate to your dashboard.
Under “First factors,” select the methods of authentication you would like to allow. While you can choose as many methods as you’d like, we recommend just a few to keep it simple.
Email verification works with Userfront right out of the box. Just click the toggle, and users can log in using a code sent by Userfront.
Similarly, email magic links also work out of the box and do not need to be configured. If you prefer to build your own magic link experience, follow these instructions.
To set up SSO, you will need to follow the steps for each SSO provider.
To set up TOTP, follow these instructions.‍

Passwordless authentication is a solid solution for organizations aiming to enhance their security and user experience. With platforms like Userfront, implementing passwordless authentication is a straightforward process.‍

Originally posted here - sign up with Userfront & get started today.

Why I Love Building Userfront

Tyler Warnock — Thu, 27 Jun 2024 23:01:16 +0000

Hi, I’m Tyler. I’m the founding CEO at Userfront, and I want to share why I’m here and why I love working on Userfront every day.

My cofounder Damion and I have each been writing software for over a decade; in my case it’s about 20 years. My software background started with missile defense research for DARPA, where I wrote code to control hardware in supersonic dynamic systems, and then robotics at Stanford, where I focused on building novel medical devices.

My old wind tunnel setup

When I started writing software specifically for the internet and startups in 2012, I found all the “extra stuff” to be a nuisance. User administration, password resets, file uploads, email sending… why can’t I just build my app? I was on Ruby on Rails at the time, and the gem plugin ecosystem (as narrated by Ryan Bates at RailsCasts) is the only reason I was able to build anything useful at all.

Still, I stuck with it, and as I became more sophisticated, I noticed patterns emerging. My first approach to handling all the “extra stuff” was to pick a basic solution and move on. This works great because extra features are YAGNI (”You Aren’t Gonna Need It”), and moving quickly at the beginning matters a lot. But I also learned that this strategy is painful for certain foundational systems, particularly databases and auth. Both are hard to change once you have them in place, so you really want to make sure that whatever you choose will have what you need later, even if you don’t need it right now. For these foundational systems, it’s less “You Aren’t Gonna Need It” and more “You Will Need It - Just Not Right Now” (YWNI-JNRN™).

For databases, I came to love Postgres, and at this point you’ll have a tough time convincing me to start with something else. Auth on the other hand… there were always pros and cons and opinions and tradeoffs. Damion & I never found something that really nailed it and fit the bill for a growing software company. Simple plugins make it easy to get started, but simple plugins don’t model intermediate or advanced needs. If you start with individual user accounts and later need to serve team accounts, you’re going to have a bad time. If you start with freemium customers and later want to serve enterprise customers, you’re going to have a bad time. If you start with session tokens and later need to scale horizontally, you guessed it… you’re going to have a bad time.

It seems like the instant you get off of the happy path for auth, everything jumps straight from “this takes 7 seconds to set up” to “read our PhD-level Zanzibar whitepaper”. Either you’re doing the basics, no problem, or you need to be a master artisan.

In other words, auth is like the meme for drawing an owl:

And this is why I love working on Userfront: we’re drawing the auth owl for thousands of software companies. I love helping people solve their growing pains because it feels like paying it forward. I’ve found that almost everyone wants to build things that make the world better, and we get to help them do that. Every important transaction and every piece of data relies on auth, and we get to help software companies spend less time figuring it out as they go. We get to help software companies succeed.

Didn't want to bother support, but wanted to give you guys some feedback — you guys are rockstars and my developers love working with your product and you are amazing at support requests as well. Cheers!

Kunal Shah, Co-Founder and Managing Director, Accelerate BSi

At this point, I’ve spoken with almost 1,000 software companies about their auth needs, and I’ve seen every configuration you can imagine. These are the things that I believe matter most for companies and developers:

Auth wishlist

Should Have	Should Not Have
Fast and free to get started, no credit card required	Complex mental model with lots of diagrams
Flexible architecture to handle all types of customers (freemium, organizations, enterprise)	Vendor lock-in and squeeze
Amazing docs	Circular docs
Secure and compliant by default	Security footguns, or compliance as an afterthought

This list is what we’re building at Userfront, and I love being a part of it. We have a thoughtful, world-class team who have built complicated systems and who care about getting it right. We sweat the details of the auth owl together so that software companies don’t have to. In doing so, we’ve built something rock solid that our customers rave about.

It feels amazing to create something that moves the needle for people in such a concrete way. We love celebrating with companies when they win a big new customer, or when we enable a feature that levels up their product. We love building a solid tool that companies don’t have to rip and replace in a year, and we love giving people a roadmap of what’s coming next on their journey.

At the end of the day, we’re all trying to build something great, and I love that Userfront is helping software companies do just that.

Learn more about Userfront on our website.