An Adapter in NextAuth.js connects your application to whatever database or backend system you want to use to store data for user accounts, sessions, etc.
You do not need to specify an adapter explicitly unless you want to use advanced options such as custom models or schemas, if you want to use the Prisma adapter instead of the default TypeORM adapter, or if you are creating a custom adapter to connect to a database that is not one of the supported databases.
Configure your database by creating the tables and columns to match the schema expected by NextAuth.js.
NextAuth.js comes with a default adapter that uses TypeORM so that it can be used with many different databases without any further configuration, you simply add the node module for the database driver you want to use to your project and pass a database connection string to NextAuth.js.
The default adapter is the TypeORM adapter, the following configuration options are exactly equivalent.
The tutorial Custom models with TypeORM explains how to extend the built in models and schemas used by the TypeORM adapter. You can use these models in your own code.
synchronize option in TypeORM will generate SQL that exactly matches the documented schemas for MySQL and Postgres.
However, it should not be enabled against production databases as it may cause data loss if the configured schema does not match the expected schema!
You can also use NextAuth.js with Prisma.
To use this adapter, you need to install Prisma Client and Prisma CLI:
Configure your NextAuth.js to use the Prisma adapter:
While Prisma includes an experimental feature in the migration command that is able to generate SQL from a schema, creating tables and columns using the provided SQL is currently recommended instead as SQL schemas automatically generated by Prisma may differ from the recommended schemas.
schema.prisma file similar to this one:
datasource option appropriately for your database:
Once you have saved your schema, you can run the Prisma CLI to generate the Prisma Client:
You can add properties to the schema and map them to any database column names you wish, but you should not change the base properties or types defined in the example schema.
The model names themselves can be changed with a configuration option, and the datasource can be changed to anything supported by Prisma.
You can use custom model names by using the
modelMapping option (shown here with default values).
If you experience issues with Prisma opening too many database connections in local development mode (e.g. due to Hot Module Reloading) you can use an approach like this when initalising the Prisma Client:
See the tutorial for creating a database adapter for more information on how to create a custom adapter.