Is next-auth the right choice for me?

[kirkegaard]

Im wondering if next auth is a fit for our new platform. We are currently using a cookie session based setup but are looking at porting to a jwt approach. We've made an authentication service that we would like to use. An example of a access/refresh token can be seen here:

curl -X POST -d "[email protected]&password=password&grant_type=password" http://localhost:9090/token |jq

{
  "access_token": "eyJhbGciOiJSUzI1NiJ9.eyJwcm9maWxlX2lkIjoxMDAwMCwiaWF0IjoxNjMwNTc5OTQ0LCJleHAiOjE2MzA1ODM1NDR9.3w0Tn98DMjPJ6Bo6TX6-sKfE-dyI3y-RdBbMW1ajb3TgdKJAzaj7f1v_1KVyx2KSJV4DzB-0IfjtO0dqUdZE8st3R8ZbKVQzFo-uonbE30d201PLBZUjgWjod8lexEcQvbqf9irw2yTnj85Lfr5ZNynzEJfFVfQ0VxiLbuuHcYyzvHW5nCCHx1Yc9jnXL2zL1moYmowrcuIDvQHtapNBZsCMsaBd2Fndf5Yvu4kzxYdMfjnKLk51ZSU2WBal1LtrDCMqamX-wC4_hh808vxwyvrLZEaSMfBJeF27Y1liF4mM6ZF1h59sIwRSGML0tvSlYhRkQt4vPfMon2J50cRLCA",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "eyJhbGciOiJSUzI1NiJ9.eyJwcm9maWxlX2lkIjoxMDAwMCwiaWF0IjoxNjMwNTc5OTQ0LCJleHAiOjE2MzA1ODM1NDR9.3w0Tn98DMjPJ6Bo6TX6-sKfE-dyI3y-RdBbMW1ajb3TgdKJAzaj7f1v_1KVyx2KSJV4DzB-0IfjtO0dqUdZE8st3R8ZbKVQzFo-uonbE30d201PLBZUjgWjod8lexEcQvbqf9irw2yTnj85Lfr5ZNynzEJfFVfQ0VxiLbuuHcYyzvHW5nCCHx1Yc9jnXL2zL1moYmowrcuIDvQHtapNBZsCMsaBd2Fndf5Yvu4kzxYdMfjnKLk51ZSU2WBal1LtrDCMqamX-wC4_hh808vxwyvrLZEaSMfBJeF27Y1liF4mM6ZF1h59sIwRSGML0tvSlYhRkQt4vPfMon2J50cRLCA",
  "scope": null
}

What im wondering is if its possible to use credentials and the password grant type with next-auth?
It also looks like it relays on the /api endpoint for callbacks. This is a problem for our site since the /api is taken up by another service. My thoughts were that this is only for other grant types but i couldnt really find anything on it.
During this year we're also implementing a danish service called nemid/mitid. Mitid will be a straight up oauth2 token based approach so that should be doable. If anyone knows a bit about this that would also be appreciated :)

I hope someone could give me some pointers on what to do and how to work around these things :)

[balazsorban44]

you can use the authorize callback of the credentials provider to send credentials to your api and get back the result in the jwt and session callbacks:

https://next-auth.js.org/providers/credentials

https://next-auth.js.org/configuration/callbacks

[kirkegaard]

Yes token rotation :) But also how provider data in next-auth is working. What i ended up with was this and it seems to do the trick. Although im curious if this is what you mean by not sending the tokens to the client? What i end up with is this when i ask for the session through useSession()

Am i missing anything?

import NextAuth from "next-auth";
import Providers from "next-auth/providers";

const ENDPOINT = "http://localhost:9090/token";

const defaultHeaders = {
  Accept: "application/json",
  "Content-Type": "application/x-www-form-urlencoded",
};

async function refreshAccessToken(token) {
  try {
    const response = await fetch(ENDPOINT, {
      method: "POST",
      body: new URLSearchParams({
        refresh_token: token.refreshToken,
        grant_type: "refresh_token",
      }),
      headers: { ...defaultHeaders },
    });

    const refreshedTokens = await response.json();

    if (!response.ok) {
      throw refreshedTokens;
    }

    return {
      ...token,
      accessToken: refreshedTokens.access_token,
      accessTokenExpires: Date.now() + refreshedTokens.expires_in * 1000,
      refreshToken: refreshedTokens.refresh_token ?? token.refreshToken,
    };
  } catch (error) {
    console.log(error);

    return {
      ...token,
      error: "RefreshAccessTokenError",
    };
  }
}

export default NextAuth({
  providers: [
    Providers.Credentials({
      name: "Credentials",
      credentials: {
        username: { label: "Email", type: "text" },
        password: { label: "Password", type: "password" },
      },
      async authorize(credentials, req) {
        const res = await fetch(ENDPOINT, {
          method: "POST",
          body: new URLSearchParams({
            ...credentials,
            grant_type: "password",
          }),
          headers: { ...defaultHeaders },
        });

        const token = await res.json();

        if (res.ok && token) {
          return {
            ...token,
            name: "John Doe",
            email: "[email protected]",
          };
        }

        return null;
      },
    }),
  ],

  session: {
    jwt: true,
    maxAge: 3600,
  },

  jwt: {
    secret: process.env.JWT_SECRET,
    encryption: true,
  },

  callbacks: {
    async jwt(token, user) {
      if (user) {
        return {
          accessToken: user.access_token,
          accessTokenExpires: Date.now() + user.expires_in  * 1000,
          refreshToken: user.refresh_token,
          user,
        };
      }

      if (Date.now() < token.accessTokenExpires) {
        return token;
      }

      return refreshAccessToken(token);
    },

    async session(session, token) {
      if (token) {
        session.user = {
          name: token.user.name,
          email: token.user.email,
        };
        session.accessToken = token.access_token;
        session.error = token.error;
      }

      return session;
    },
  },
});

[kirkegaard]

and again, thank you so much for your help!

[balazsorban44]

Yep, that looks good to me!

One thing you might have missed is that the jwt callback's returned result is the second argument of the session callback. So you mixed up access_token and accessToken, that's why you don't see it on your screenshot. Also, you do not need the if statement in the session callback.

[kirkegaard]

Aah you're right! I missed that! Thank you so much :) This really cleared things up for me!

[kirkegaard]

One last thing :)
The expires date in the /api/auth/session endpoint and cookie is set to the current time on every request. But shouldnt that be the same expire date as the one i calculate in the jwt callback? Or does next-auth use the exp inside the access token when requesting the sessions endpoint to know when to do the refresh?

Our tokens is set to one hour, so should i set the maxAge and the clientMaxAge to something lower?

In our "real" setup we would probably want idle sessions to die after 30 minutes. Although as long as the refresh token is still valid it should just ask our auth service for a new access token? In that case maxAge should probably be 30 minutes and clientMaxAge something lower like 10 minutes?