Proposals for NextAuth 2.0

[iaincollins]

Proposal for NextAuth 2.0

The following proposal is what is planned for NextAuth 2.0. Some of these features have already made it into 1.5. Others are in progress. It is an active work in progress but there is no fixed ETA yet.

Comments and feedback are welcome.

Updated 29 May, 2018.

Simpler Configuration

The core rationale for NextAuth 2.0 is to make it much simpler to use, so that instead of 3 configuration files all you will need is to use it is to do something like this:

const next = require('next')
const nextAuth = require('next-auth')

require('dotenv').load()

const nextApp = next({
  dir: '.',
  dev: (process.env.NODE_ENV === 'development')
})

nextApp
.prepare()
.then(() => {
  return nextAuth.load(nextApp, {
     serverUrl: process.env.SERVER_URL,
     port: process.env.PORT,
     functions: NextAuth.Functions(process.env.CONNECTION_STRING),
     sessions: NextAuth.Sessions(process.env.CONNECTION_STRING),
     email: {
       from: process.env.EMAIL_FROM,
       host: process.env.EMAIL_SERVER,
       port: process.env.EMAIL_PORT,
       username: process.env.EMAIL_USERNAME,
       password: process.env.EMAIL_PASSWORD
     },
     providers: {
       "Facebook": {
         provider: NextAuth.Facebook,
         id: process.env.FACEBOOK_ID,
         secret: process.env.FACEBOOK_SECRET
       },
       "Twitter": {
         provider: NextAuth.Twitter,
         id: process.env.TWITTER_ID,
         secret: process.env.TWITTER_SECRET
       }
     }
   })
})
.then(response => {
  console.log(`Ready on http://localhost:${response.port}`)
})
.catch(err => {
  console.log('An error occurred, unable to start the server')
  console.log(err)
})

It will include built in support for at least Mongo DB and MySQL and use the connection string to detect database type (e.g. checking if it starts withmongodb:// or mysql://).

It will still be possible to define your own functions to integrate with another database. Having examples for both an SQL and NoSQL database should make it easy to create adapters for other databases.

New Features

Changes to Session Storage and CSRF Tokens

There are some changes to the way session storage will be handled:

• The implementation of Cross Site Request Forgery tokens will switch to the Double Submit Cookie method, which does not require a server side session.

• A session in a databases will only be created for a user when they log in, to reduce database load - this also helps provide some protection against trivial Denial of Service attacks.

• CSRF will be an option, and it will be possible to set it to null or to explicitly pass a method which can be used to disable it on white listed routes if required.

NextAuth Pages

• Built in 'white labeled' pages for displaying a sign in dialog and linking/unlinking accounts.

• Built in 'white labeled' pages for callbacks, error handling and email token messages.

These will be the default but you will specify your own URLs if you wished:

pages: {
  signin: "/signin",
  callback: "/callback",
  checkEmail: "/check-email",
  error: "/error"
}

## NextAuth Components

We will also expose the components used to make these pages (e.g. <NextAuth.SignInButton/>, <NextAuth.SignOutButton/>), to make it easier to add them to a site.

Going further, a basic page will also be exported as NextAuth.React.Component to automatically add session data to every page if used in place of React.Component when declaring a page. It will otherwise work exactly like a React page in Next.js.

Example

import React from 'react'
import { NextAuth } from 'next-auth'
 
export default class extends NextAuth.React.Component {
  render() {
    if (this.props.session) {
      return(
        <React.Fragment>
          <p>You are logged in as {this.props.session.user.name || this.props.session.user.email}.</p>
          <NextAuth.SignOutButton/>
        </React.Fragment>
        )
    } else {
      return(
        <React.Fragment>
          <p>You are not logged in.</p>
          <NextAuth.SignInButtons/>
        </React.Fragment>
      )
    }
  }
}

These components will take options like <NextAuth.SignInButtons className="btn btn-primary"> to allow them to be easily styled. They will be simple HTML elements with perhaps (optional) JavaScript behaviour bound to them.

Built in Database support

• Bundled strategies for both session and user databases - including as an in-memory DB, Mongo DB and MySQL.

• It will still be possible to define your own methods for other session and database stores (and this will be easier than it is now - so it shouldn't matter which SQL or NoSQL DB you are using).

• The session and user database stores will not have to be the same database or even the same type of database.

Internally, the functions might change to make this easier, so that instead of general purpose database methods like update() and insert() they might be named after actions such as createUser(), linkProvider(), unlinkProvider(), generateSigninToken(), etc.

This will mean slightly more functions will need to be defined than in 1.x, but they will be explicit in functionality so that they can be more single purpose and easier to adapt to different databases.

If the database type in the connection string is one of the supported types, it will load the appropriate config, connect (and check the table structure if an SQL database, creating tables and columns as required if they don't existing) then return pre-configured strategy so it "just works" out of the box.

NextAuth will of course need to be updated to only start once the promise returned by NextAuth.Functions() and NextAuth.Sessions() had returned

• Provider configuration will be much simpler for common providers.

We'd only bundle support for a few simple commonly used strategies - such as Facebook, Twitter and Google, but you'd still be able to define your own for any oAuth provider - the same way they are already configured for NextAuth.

Optional parameters for each Provider will include:

• callback - A URL that can be defined for each provider; this has already been added to 1.x as a requested feature since this was written.
• seralize - A function to normalize user objects from third party services.

Additionally, it will be easier to add support for password and/or two factor based authentication. Functionality for this has been added to 1.x but the support for this will improve.

Better NextAuth Email

• Built in email templates.

I'd like to include nice looking HTML email templates for sending emails and bundle nodemailer.

This behaviour should of course still be able to be overridden as it is now.

Bundle NextAuthClient

I'd like to expose NextAuthClient directly in NextAuth (as NextAuth.Client) if this can be done simply and cleanly.

It will provide a simpler way to use NextAuth and ensure both will be updated easily and were always in sync.

NextAuth.Client is now already available in 1.x as it made sense to simplify how it was used and didn't require major changes client side.

The bundler for NextAuth.Client may change at some point, as there are some issues with newer webpack releases that mean it no longer generate isomorphic libraries that also run in service workers correctly (so for now we are not using the latest-and-greatest webpack to build it, as older versions work fine for universal apps) but even if we do that shouldn't change how it is used.

Rollup is one option and is much simpler, though it doesn't support Hot Module Replacement (HMR) and that might be a problem.

[iaincollins]

To clarify, there is no planned release timeframe for 2.0 yet - and 1.x is will continue to see new feature work before 2.0, as some good feature requests for things like localStrategies and other options have come in that are easy to deal with without any breaking API changes required, so they will likely get priority.

[iaincollins]

Some work has already been done by others to add better database support for 1.5 - specifically MySQL support - and we may just share that in the interim, if we can get it documented, ready to share and they agree.

For 2.0 though, we are thinking of increasing the number of discrete database calls, with the trade off being they do specific things and ultimately requires less code (and simpler code), especially when interacting with SQL databases.

As a result of them being easier to write, it would include built-in support for at least both Mongo DB and MySQL out of the box.

This is an example of the sort of methods a DB driver for NextAuth 2.0 would need to support:
https://github.com/iaincollins/next-auth/blob/version-2.0/src/function/mysql.js

Feedback welcome!

[jjwilliams42]

I like this path forward, and it confronts my feeling that this project it a bit complex to put in place easily. I have a project I'm starting (about 6 pages in), and thought it may be easier to use the starter auth and copy my stuff in.

Thanks for this project, it's looking good!

[iaincollins]

Thanks for the feedback!

I agree it's too complicated as it is, but am very glad for the feedback I've gotten and issues the existing implementation has raised.

I've been focused on making progress on another commercial projects (which uses next-auth) and looking forward to revisiting it for 2.0 soon.

[falleco]

Hello, @iaincollins are you accepting help with the 2.0 version? I can help with the simpler configuration point. But the 2.0 branch seems like untouched by ~1 year... What are your plans?

[iaincollins]

Hi @falleco thank you for asking and for reaching out - and to everyone else for feedback.

After a long period of dormancy - mostly due to the evolving nature of Next.js and Now.sh over the last year - I've picked up work on NextAuth 2.0!

[iaincollins]

tl;dr Much of this has been done already this week (as of v2.0 beta 10) and the rest is coming soon! Closing this thread, follow the NextAuth 2.0 announcement for updates.