Federated logout (OpenID Connect)

[balazsorban44]

Summary of proposed feature

Acces id_token in jwt callback, when idToken: true in a provider's option.

Purpose of proposed feature

Make it possible to start a logout process from a next app using next-auth that will log out from the Identity Provider entirely, if it is OIDC compliant.

Detail about proposed feature

OpenID Connect compliant IdPs (like IdentiyServer4, which is also supported by next-auth) have a federated logout.
To initiate such a logout process, when signOut() is called, next-auth should redirect to https://idp.com/endsession, and forward at least the two following query params:

1. id_token_hint: The original id_token received from the IdP at login.
2. post_logout_redirect_uri: A preconfigured URL in the IdP client, that the IdP should redirect to after a successful logout. This could default to NEXTAUTH_URL, but could be overridden in a provider setting. (Note that the same url must be registered in the IdP client)

Additional optional query params exist, see the relevant spec section

Obtaining the id_token at the initial jwt() callback call would make it possible to preserve it in a session database, or in the jwt token itself.

Potential problems

• According to the JWT callback docs jwt callback has already many parameters, and adding a new idToken would just make it worse. In my opinion should/could be provided as a single object to basically be able to use named params, but that would be a breaking change.

• Setting the id_token in the JWT cookie is kind of an overhead, as the cookie most possibly contains some kind of a mapping of the id_token (name, email, etc.) already. My solution for this would be to not store it in the cookie, but create an in-memory database (just a JS class with key value pairs, where keys are user ids, and each user contains a list of sessions, containing sessions' id_tokens. Hint: The id_token usually contains a sid or Session ID, and timestamps if needed). Adding such an in-memory database should not be required from most of the users though. (Although this could very well be an optional part of next-auth, that could also complement RFC: Limit logins (by concurrency, location) #583 nicely, which I am already working on at work, and some day be able to share it as a PR to next-auth) I am open for suggestions here!

• There is the 4096 bytes cookie size limit in browser, and because of that every extra bytes count, if we cannot somehow divide the data into multiple cookies somehow. (I am no expert on cookies though, so I do not know hard it would be to split/merge cookies)

Describe any alternatives you've considered
I haven't considered alternatives to next-auth as it is generally a high quality full auth solution for Next.js apps, and since it already supports idToken for OIDC compliant IdPs, it would only make sense to leverage that even further.

Additional context
OIDC spec: https://openid.net/specs/openid-connect-rpinitiated-1_0.html
Relevant IDS4 documentation: https://identityserver4.readthedocs.io/en/latest/endpoints/endsession.html
id_token content: https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens#payload-claims

Please indicate if you are willing and able to help implement the proposed feature.

If this is not a problem that can be solved in user land right now, I may be willing to try to implement this and open a PR for it, but before that, I need feedback on how to store the id_token in the jwt callback, with minimal overhead.

So just a TLDR:

If the user provides the idToken: true option as a Provider option, it would be nice to send it as a param to the jwt callback as well. The rest can strictly speaking be implemented by the user for now.

[balazsorban44]

#1024 solved this by passing the idToken to the jwt and signIn callbacks through profile.idToken.

Then you can save the token in the JWT, and reuse it when logging the user out.

For this I created a custom api endpoint:

// /api/auth/federated-logout
import jwt from "next-auth/jwt"
import log from "utils/server-logger"

export default async function federatedLogout(req, res) {
  try {
    const token = await jwt.getToken({req, secret: process.env.SECRET, encryption: true })
    if (!token) {
      log.warn("No JWT token found when calling /federated-logout endpoint")
      return res.redirect(process.env.NEXTAUTH_URL)
    }
    if (!token.idToken)
     log.warn("Without an id_token the user won't be redirected back from the IdP after logout.")

    const endsessionURL = `https://${process.env.PROVIDER_DOMAIN}/connect/endsession`
    const endsessionParams = new URLSearchParams({
      id_token_hint: token.idToken,
      post_logout_redirect_uri: process.env.NEXTAUTH_URL,
    })
    return res.redirect(`${endsessionURL}?${endsessionParams}`)
  } catch (error) {
    log.error(error)
    res.redirect(process.env.NEXTAUTH_URL)
  }
}

And when logging out on the client:

<button onClick={() => window.location.href = "/api/auth/federated-logout"}>
  Sign out
</button>

[LauSam09]

Balazsorban's answer almost worked for me as I was able to end the OAuth provider session, but the next-auth session was still active upon being redirected back to my application. This meant that the user still appeared logged in.

Manually removing the next-auth session cookie as below resolved this for me:

export default async function federatedLogout(req, res) {
  try {
    const token = await jwt.getToken({req, secret: process.env.SECRET, encryption: true })
    if (!token) {
      log.warn("No JWT token found when calling /federated-logout endpoint")
      return res.redirect(process.env.NEXTAUTH_URL)
    }
    if (!token.idToken)
     log.warn("Without an id_token the user won't be redirected back from the IdP after logout.")

    const endsessionURL = `https://${process.env.PROVIDER_DOMAIN}/connect/endsession`
    const endsessionParams = new URLSearchParams({
      id_token_hint: token.idToken,
      post_logout_redirect_uri: process.env.NEXTAUTH_URL,
    })
+   res.setHeader(
+     "Set-Cookie",
+     "next-auth.session-token=deleted; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT"
+   );
    return res.redirect(`${endsessionURL}?${endsessionParams}`)
  } catch (error) {
    log.error(error)
    res.redirect(process.env.NEXTAUTH_URL)
  }
}

[BradNut]

@LauSam09 I was also trying Balazsorban's answer but when using just NextAuth's getToken() method the response token was always null. Did you also face this issue?

I see that you have it slightly different as jwt.getToken(...). What is this jwt portion?

[LauSam09]

@BradNut yes I did also face that issue - perhaps that form of importing worked for older versions of next-auth, I'm not sure?

I didn't change what I used in my code sample as I wanted to highlight the main difference that I was adding which was setting the header. I actually used this import below instead. See https://next-auth.js.org/tutorials/securing-pages-and-api-routes#using-gettoken

import { getToken } from "next-auth/jwt";

// ...
const token = await getToken({ req });

Whilst I'm here, my res.setHeader solution worked fine in development, but for production builds Next.js generates a secure cookie that is named differently. Expiring both all the time seems to work just fine for both development and production builds:

  res.setHeader("Set-Cookie", [
    "next-auth.session-token=deleted; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT",
    "__Secure-next-auth.session-token=deleted; path=/; Secure; expires=Thu, 01 Jan 1970 00:00:00 GMT",
  ]);

Hope this helps!

[BradNut]

Hey @LauSam09. I did finally end up getting this working. My issue I believe was resolved by omitting declaring a different but the same SECRET env variable and letting it all fall back to just the NEXTAUTH_SECRET.

As an FYI I did not have this issue of having to manually remove the session/secure-session cookies. However my testing has not been on full production builds yet.

This is on:

"next": "13.0.6",
"next-auth": "^4.18.10",

One thing I did notice however is that this whole flow only works if I have the .then logout on the promise call to postfederatedLogout vs. trying to implement logging out on redirected page. This is if you want to use post_logout_redirect_uri to a page which in turn does the logout.

Either case yields a CORS error (Different domains for the Auth server) but with the promise approach you at least get the Next App logged out because of this promise. Because of CORS no redirection would occur without the signOut.

I am hoping moving the Auth server to a subdomain or adding CORS functionality will fix this...we'll see.

[jschuckm]

Only thing is logout should be a POST request not a GET request since it is changing the user state and browsers can prefetch routes from GET requests and incidentally log users out. https://stackoverflow.com/questions/3521290/logout-get-or-post https://www.baeldung.com/logout-get-vs-post#:~:text=Even%20in%20a%20stateless%20environment,explicit%20intent%20to%20log%20out.

// /api/auth/federated-logout
import jwt from "next-auth/jwt"
import log from "utils/server-logger"

export default async function federatedLogout(req, res) {
  if(req.method === 'POST'){
     // Do the logout
  }
}

[balazsorban44]

Reopening, as this has not been fully resolved. We could try to support federated logout for most OIDC compliant providers out-of-the-box.

[bardsol]

Any word on this feature?

[ShawnCentra]

I'm actively working on a solution for this right now as I dont believe its been implemented yet.

[Robert-OP]

Hey @balazsorban44 - thanks for opening this issue. I was looking into this as well because I was working on implementing next-auth with Azure AD B2C. In my case in order to sign out, it requires the id_token_hint which I need to attach basically as a query parameter as so

https://${process.env.AUTH_TENANT_NAME}.b2clogin.com/${process.env.AUTH_TENANT_NAME}.onmicrosoft.com/${process.env.USER_FLOW}/oauth2/v2.0/logout?post_logout_redirect_uri=${process.env.NEXTAUTH_URL}/auth/signout&id_token_hin=${id_token_hint}

Basically that is the id_token that I got when signing in and it's stored in the session. Do you know how can I retrieve this token such that I attach it to my request URL above?

Or would it be possible to resolve this in a different way?

Cheers,
Robert

[balazsorban44]

So my current solution for this is using the canary release, where you have the ID token available in the jwt callback (in the account param). I save it in the session cookie, and then I created an api route in Next.js that reads the ID token from the cookie, and sends the logout request from there. Works like charm! only we should make it so that users don't have to do it themselves.

[Robert-OP]

Thanks @balazsorban44 - how do you save the ID token from the jwt callback into the session cookie and then retrieve it from the cookie?

I went on to implementing the above using the canary release, I can see the idToken in signIn callback and also on the first jwt callback, but after I don't get the idToken in the jwt callback anymore. So, I don't know how can I pass it to the federated-logout when calling jwt.getToken({ req, secret: process.env.JWT_SECRET, encryption: true }); function. Any ideas?

callbacks: {
    async signIn(token, account, profile) {
      console.log('### signIn \n', token, account, profile);
      return true;
    },
    async jwt(token, account, profile) {
      console.log('### jwt \n', token, account, profile);
      return token;
    },
}

[kn327]

The id_token is supplied only on first login.

According to the docs, the jwt method is called any time a new token is generated by next-auth internally. So you need to check to ensure that the account prop has a value - I actually just stick the id_token directly into the returned token value at initial signin and it's persisted by next-auth so I can get to it any time I call into the getToken method on the server.

For a more secure implementation, it could be helpful to encrypt this value to ensure if it's ever leaked to a client, it cannot be used maliciously

[balazsorban44]

Have a look at the jwt callback canary docs https://next-auth-git-canary.nextauthjs.vercel.app/configuration/callbacks#jwt-callback 😉

[Robert-OP]

Cheers @balazsorban44 - forgot to look in the canary docs, works like a charm. Thanks a lot for the help! 🙏

[Xodarap]

Hi all, is an implication of this issue that people are not able to, say, switch from one Google account to another?

I'm seeing that behavior on my site and wondering if this is the cause.

[balazsorban44]

You can always force a new user to login with their own credentials using prompt=login

https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

To make it work in next-auth, you could do: signIn("google", undefined, { prompt: "login" })

https://next-auth.js.org/getting-started/client#additional-params

[Xodarap]

Thanks! The user is being prompted, but the issue I'm seeing is that next auth doesn't use the new account. E.g.

1. Log in with [email protected].
2. Logout
3. Log in with [email protected]
4. Next auth thinks you logged in with [email protected]

This still occurs with prompt: login or prompt: select_account

[iaincollins]

Thanks! The user is being prompted, but the issue I'm seeing is that next auth doesn't use the new account. E.g.

1. Log in with [email protected].
2. Logout
3. Log in with [email protected]
4. Next auth thinks you logged in with [email protected]

This still occurs with prompt: login or prompt: select_account

It sounds like they are not being signed out from the first session in NextAuth.js (i.e. that the existing session cookie is not being deleted).

Note

If you are using a database and sign a user with a second OAuth account while they are already signed in it will securely link the accounts; the user information returned in the session will be whatever the email addresses associated with the User ID is (e.g. the email address associated with the first account they signed in with).

If this is the case it is easy to view by looking at the User and Accounts tables, you will see the Accounts are both referenced to the same User ID. To unlink the OAuth accounts, simply delete the entry for the account in the Accounts table.

NB: Build in pages to allow users to link/unlink accounts and to edit their profile settings are planned, but for now you would need to build your own interface to handle this.

If you are not using a database then it will swap the two instead of linking (as linking accounts without a database doesn't make sense without a database to track which accounts are linked).

[yuriy-eleks]

#1024 solved this by passing the idToken to the jwt and signIn callbacks through profile.idToken.

Then you can save the token in the JWT, and reuse it when logging the user out.

For this I created a custom api endpoint:

// /api/auth/federated-logout
import jwt from "next-auth/jwt"
import log from "utils/server-logger"

export default async function federatedLogout(req, res) {
  try {
    const token = await jwt.getToken({req, secret: process.env.SECRET, encryption: true })
    if (!token) {
      log.warn("No JWT token found when calling /federated-logout endpoint")
      return res.redirect(process.env.NEXTAUTH_URL)
    }
    if (!token.idToken)
     log.warn("Without an id_token the user won't be redirected back from the IdP after logout.")

    const endsessionURL = `https://${process.env.PROVIDER_DOMAIN}/connect/endsession`
    const endsessionParams = new URLSearchParams({
      id_token_hint: token.idToken,
      post_logout_redirect_uri: process.env.NEXTAUTH_URL,
    })
    return res.redirect(`${endsessionURL}?${endsessionParams}`)
  } catch (error) {
    log.error(error)
    res.redirect(process.env.NEXTAUTH_URL)
  }
}

And when logging out on the client:

<button onClick={() => window.location.href = "/api/auth/federated-logout"}>
  Sign out
</button>

@balazsorban44 Is it possible without process.env.SECRET ? With Client secret from okta console returns null

[balazsorban44]

Not really sure what you mean. the secret is used to retrieve the token with getToken, because I encrypted it. Not really sure what you mean by client secret from okta console.

See the docs: https://next-auth.js.org/configuration/options#jwt

[alessandrojcm]

#1024 solved this by passing the idToken to the jwt and signIn callbacks through profile.idToken.

Then you can save the token in the JWT, and reuse it when logging the user out.

For this I created a custom api endpoint:

// /api/auth/federated-logout
import jwt from "next-auth/jwt"
import log from "utils/server-logger"

export default async function federatedLogout(req, res) {
  try {
    const token = await jwt.getToken({req, secret: process.env.SECRET, encryption: true })
    if (!token) {
      log.warn("No JWT token found when calling /federated-logout endpoint")
      return res.redirect(process.env.NEXTAUTH_URL)
    }
    if (!token.idToken)
     log.warn("Without an id_token the user won't be redirected back from the IdP after logout.")

    const endsessionURL = `https://${process.env.PROVIDER_DOMAIN}/connect/endsession`
    const endsessionParams = new URLSearchParams({
      id_token_hint: token.idToken,
      post_logout_redirect_uri: process.env.NEXTAUTH_URL,
    })
    return res.redirect(`${endsessionURL}?${endsessionParams}`)
  } catch (error) {
    log.error(error)
    res.redirect(process.env.NEXTAUTH_URL)
  }
}

And when logging out on the client:

<button onClick={() => window.location.href = "/api/auth/federated-logout"}>
  Sign out
</button>

Hi @balazsorban44, I'm trying this snippet, and it signs the user out from the auth provider successfully (if I go to the auth provider's panel it prompts me to lo in again, I'm using FusionAuth. But when the federated-logout endpoint redirects me back to the app, it still contains a valid session somehow (i.e the app calls /api/auth/session and it still returns the access token). Any ideas on why is that? Sorry if I'm missing something obvious here 😅

[balazsorban44]

you will need to call signOut to actually remove the session cookie. unfortunately the IdP cannot change cookies of other sites.

[evanwang0]

Looking for this to be a feature built into next-auth. I am willing and able to help implement the proposed feature.

[shahinghasemi]

For keycloack this is a workable solution:

// pages/api/auth/logout
export default (req, res) => {
  res.redirect(
    `${keycloakBaseUrl}/logout?redirect_uri=${encodeURIComponent(redirectUri)}`,
  );
};

<LogoutButton
  onClick={() =>
    signOut({
      redirect: true,
      callbackUrl: '/api/auth/logout',
     });
   }}
/>

[gokhandemirhan]

For some reason, I still had the cookie after using signout with redirect false, after returning from federation logout. I've solved it with useEffect

import { signOut, useSession } from 'next-auth/react';
import { useRouter } from 'next/router';
import { useEffect } from 'react';

export default function Logout() {
  const router = useRouter();
  const { data, status } = useSession();

  useEffect(() => {
    if (data && status === 'authenticated') {
      signOut();
    } else if (status === 'unauthenticated') {
      router.push('/');
    }
  }, [data, status]);

  return <p>Logging out...</p>;
}

[JSONRice]

You still need to call the HTTP GET /logout before the signOut The sign out just removes the local session. Hitting that logout tells the server the session is done.

[shirish87]

I specifically had an issue with other solutions when Amazon Cognito was configured for sign in with phone + password OR email + password, and for my config (using adapter and session.strategy=jwt) it ended up linking 2 accounts to the same (test) user.

Looking for some feedback on federated logout for Amazon Cognito provider to clean up everything after each sign out.

Sign-out on the frontend is basically:

const signOut = async () => {
    await router.push({ pathname: '/api/auth/logout' });
};

Backend:

// pages/api/auth/logout.ts
// COGNITO_AUTH_URL=https://<id>.auth.<region>.amazoncognito.com
// Using https://docs.aws.amazon.com/cognito/latest/developerguide/logout-endpoint.html

import { NextApiRequest, NextApiResponse } from "next";

const clearCookieOptions = `Max-Age=-1; Path=/; Secure; HttpOnly;`;

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  const url = new URL('/logout', process.env.COGNITO_AUTH_URL!);
  url.searchParams.set('client_id', process.env.COGNITO_CLIENT_ID!);
  url.searchParams.set('logout_uri', process.env.NEXTAUTH_URL!);

  const cookies = Object.keys(req.cookies ?? {}).map(cookie => `${cookie}=; ${clearCookieOptions}`);

  if (cookies.length) {
    res.setHeader('Set-Cookie', cookies);
  }

  res.redirect(url.href);
}

Anyone spot any issue with this approach? Thanks.

[this-fifo]

I am also using Cognito, this solution didn't work for me unfortunately because I am using the App Router

However, I adapted to code to this and it works in case anyone has the same setup I do:

import { cookies } from 'next/headers'
import { redirect } from 'next/navigation'

const clearCookieOptions = `Max-Age=-1; Path=/; Secure; HttpOnly;`

export async function GET(req: Request, res: Response) {
  try {
    const url = new URL('/logout', process.env.COGNITO_AUTH_URL!)
    url.searchParams.set(
      'client_id',
      process.env.NEXT_PUBLIC_COGNITO_CLIENT_ID!,
    )
    url.searchParams.set('logout_uri', process.env.NEXTAUTH_URL!)

    // Clear all cookies
    let setCookies = ''
    cookies()
      .getAll()
      .forEach((cookie) => {
        setCookies += `${cookie.name}=; ${clearCookieOptions}`
        cookies().set(cookie.name, '', {
          maxAge: -1,
          path: '/',
          secure: true,
        })
        cookies().delete(cookie.name)
      })

    return new Response('', {
      status: 302,
      headers: {
        Location: url.toString(),
        'Set-Cookie': setCookies,
      },
    })
  } catch (error) {
    console.error(error)
    redirect('/')
  }
}

PS: I tried using redirect(url) with redirect from next/navigation but that throws a NEXT_REDIRECT ERROR so I did a manual 302 with Response which seemed to do the trick

PS2: I am deleting the cookies in 3 different ways, that is obviously redundant and not needed, just shared that code to show the options through adapting the previous one as well as using cookies from next/headers

[this-fifo]

It turns out the code I had worked in localhost but not in production, it took me a while to figure it out and in the process I had to change the strategy to perform the redirection client-side so I updated the route handler to return the url instead of a redirect

this is my final route.ts file

import { cookies } from 'next/headers'

const clearCookieOptions = `Max-Age=-1; Path=/; Secure; HttpOnly; SameSite=None;`

export async function GET(req: Request, response: Response) {
  try {
    const url = new URL('/logout', process.env.COGNITO_AUTH_DOMAIN!)
    url.searchParams.set('client_id', process.env.COGNITO_CLIENT_ID!)
    url.searchParams.set('logout_uri', process.env.NEXTAUTH_URL!)

    // Clear all cookies
    let setCookies = ''
    cookies()
      .getAll()
      .forEach((cookie) => {
        setCookies += `${cookie.name}=; ${clearCookieOptions}`
        cookies().set(cookie.name, '', {
          path: '/',
          maxAge: -1,
          secure: true,
          sameSite: 'none',
        })
        cookies().delete(cookie.name)
      })

    cookies().set('next-auth.session-token', '', {
      path: '/',
      maxAge: -1,
      secure: true,
      sameSite: 'none',
    })
    cookies().set('__Secure-next-auth.session-token', '', {
      path: '/',
      maxAge: -1,
      secure: true,
      sameSite: 'none',
    })

    setCookies += `next-auth.session-token=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure; SameSite=None;`
    setCookies += `__Secure-next-auth.session-token=deleted; path=/; Secure; expires=Thu, 01 Jan 1970 00:00:00 GMT`

    return new Response(JSON.stringify({ url: url.toString() }), {
      status: 200,
      headers: {
        'Set-Cookie': setCookies,
        'Content-Type': 'application/json',
      },
    })
  } catch (error) {
    console.error(error)
    return new Response('', {
      status: 302,
      headers: { Location: '/' },
    })
  }
}

export const dynamic = 'force-dynamic'

then in your app's button to logout

onClick={() => {
  fetch('/api/auth/federated-logout')
    .then((res) => {
      return res.json()
    })
    .then(({ url }) => {
      window.location.href = url
    })
    .catch((e) => console.log(e))
}}

Lastly, I want to say to whoever runs into this that I've had a tough time understanding why it wasn't working on production and it turns out the issue was because in production NextAuth will use a cookie with a __Secure prefix and it has some special rules about it you should follow otherwise the browser will ignore the Set-Cookie request and it won't clear the session https://datatracker.ietf.org/doc/html/draft-west-cookie-prefixes-05

[Ryanv030]

@shirish87 Appreciate the code snippet! I used that and had good results in getting the user actually logged out. It's a bit annoying that next-auth doesn't respect the pages: { signOut: api/auth/logout } flow.

With all that said, are you finding this is working well for you in production without issue? Getting next-auth configured with Cognito has been more of a headache than i'm willing to admit 😓

[shirish87]

Glad it helped, and yes, it does work for our use-case. We added front-end React hooks for sign-in, sign-out, session just to make sure.

From a library standpoint, one thing that would help is getting a list of cookie names under next-auth's management. In the snippet, we clear all cookies set for the domain but others may want to skip removing tracking or analytics cookies.

[mkreuzmayr]

Performing a federated logout with keycloak normally does not require the user to press the logout button manually.

For me federated logout with keycloak only works at the first time after a new account was created in the db, all following logouts require the user to manually click the logout button. I am assuming this happens because the idToken is only written to the db when an account is created, but I could be wrong about that. If I delete all rows of a user in my db and perform a fresh login it works the first time again, and every following logout needs manual action again.

Does anyone have a solution to this issue?

[ShawnCentra]

[ShawnCentra]

          <a
            onClick={async (e) => {
              await signOut({callbackUrl: "/api/auth/logout", }).then(() =>
                router.push(
                  `https://login.microsoftonline.com/${process.env.AZURE_AD_TENANT_ID}/oauth2/v2.0/logout?post_logout_redirect_uri=https://staging.portal.ca/`
                )
              );

            }}
          >
              Log Out
          </a>

also tried this way - it would redirect me to the third party azure AD auth sign out page -> and once user finishes those prompts it would redirect to the home page

Session wasn't cleared in the web application though - any further attempts to sign out say you're already signed out too.

[ShawnCentra]

Not getting session cleared even this integration.

Here's the sign out button that shoots to Azure AD's log out end point.

          <a
            href={`https://login.microsoftonline.com/${process.env.NEXT_PUBLIC_AZURE_AD_TENANT_ID}/oauth2/v2.0/logout?post_logout_redirect_uri=${process.env.NEXT_PUBLIC_NEXTAUTH_URL}/auth/signout`}
          >
              Log Out
          </a>

Here's the client side sign out page that gets redirected to from the sign out url above + Azure ADs admin config Front End Redirect url field. After the sign out runs, we redirect using the callback prop. At this point session SHOULD have been cleared, but its not. This confuses me.

import { signOut } from "next-auth/react";

export default function Signout() {
  if (typeof window !== 'undefined') {
    signOut({ callbackUrl: process.env.NEXT_PUBLIC_NEXTAUTH_URL })
  }

  return null
}

[ShawnCentra]

Okay I got it to work with Azure AD for Sign in + Sign Out

Issue is that I can't sign in or sign out too quickly. Looks like its there to prevent constant logins/logouts to their api to handle lots of users.

//log out button that initiates signOut and callbacks to Azure AD's log out flow to update both client + server side login status
//we redirect after to auth/signout which is a client side page to update the session and redirect if needed (this was to cover both cases if the session didnt update - probably a better way to do this second part, unsure if necessary need to test)
        <a
            onClick={async (e) => {
              await signOut({
                callbackUrl: `https://login.microsoftonline.com/${process.env.NEXT_PUBLIC_AZURE_AD_TENANT_ID}/oauth2/v2.0/logout?post_logout_redirect_uri=${process.env.NEXT_PUBLIC_NEXTAUTH_URL}/auth/signout`,
              });
            }}
          >
              Log Out
          </a>

// pages/auth/signout.js
import { signOut } from "next-auth/react";
import { useEffect } from "react";
import { useSession } from "next-auth/react";
import { useRouter } from "next/router";
export default function index() {
  const router = useRouter();

  const { data: session, status } = useSession();

  useEffect(() => {
    if (status === "authenticated") {
      signOut({ callbackUrl: "/" });
    } else if (status === "unauthenticated") {
      router.push("/");
    }
  }, [status]);

  return <div></div>;
}

[ShawnCentra]

Might be provider issue

[avukalov]

@ShawnCentra Front channel logout url is used when Identity Provider notifying clients that the user has signed-out.
If you sent federated logout request (end_session) then you need to set post_logout_redirect_url

This is what Identity Provider needs to do if front channel url is provided:

Front-channel server-side clients

To signout the user from the server-side client applications via the front-channel spec, the “logged out” page in IdentityServer must render an <iframe> for each client that points to the corresponding notification endpoint at the client.

Browser-based JavaScript clients

There is nothing special you need to do to notify these clients that the user has signed out.

The clients, though, must perform monitoring on the check_session_iframe, and this is implemented by spec compliant client libraries, e.g. the oidc-client JavaScript library.

[BradNut]

Did anyone get this working with the Next 13 app directory? As I stated earlier in this thread I was able to get it working with pages.

I was able to migrate NextAuth to Next 13 app directory but I had to keep the federated logout solution in the old pages API area.

[maestroAlfredo]

I did, I basically created a route handler which handles the sign out like this. My provider supports front logout so this is the configuration at the provider

FrontChannelLogoutUri: '[clientbaseurl]/signout'
PostLogoutRedirectUri: '[clientbaseurl]/'

export const nextAuthOptions : AuthOptions = {
   // Configure one or more authentication providers
   //.....
    pages: {
        signIn: '/signin',
    },
    callbacks: {
        async redirect({ url, baseUrl }) {
            // Allows relative callback URLs
            if (url.startsWith("/")) return `${baseUrl}${url}`
            // Allows callback URLs on the same origin
            else if (new URL(url).origin === baseUrl) return url
            // Allow callbacks to identity server Server    
            else if (new URL(url).origin === process.env.AUTH_SERVER_BASE_URL) return url
            return baseUrl
        },
        async jwt({token, user, account, profile}) {
            if (account?.id_token) {
                token.idToken = account.id_token;
            }
            return token;
        },
        async session({ session, token, user}) {
            // @ts-ignore
            session.idToken = token.idToken;
            return session;
        }
    },
};

//app/api/singlesignout/route.ts

import { NextResponse } from 'next/server'
import {logger} from '@/logger';
import {getServerSession} from "next-auth";
import {nextAuthOptions} from "@/app/api/auth/[...nextauth]/route";

//added this because of a dynamic error during build 
//https://stackoverflow.com/questions/76285120/error-dynamic-server-usage-headers-on-next-13-4
export const dynamic = "force-dynamic";

const handler = async () => {
    try {
        const session = await getServerSession(nextAuthOptions);
        // @ts-ignore
        const redirectUri = encodeURIComponent(process.env.NEXTAUTH_URL);
        // @ts-ignore
        const token = session?.idToken;
        const redirectUrl = token == null ? process.env.NEXTAUTH_URL : process.env.AUTH_SERVER_BASE_URL + "/connect/endsession?id_token_hint=" + token + "&post_logout_redirect_uri=" + redirectUri;
        // @ts-ignore
        return NextResponse.redirect(redirectUrl);
    } catch (err) {
        logger.error(err, "error");
        // @ts-ignore
        return NextResponse.redirect(process.env.NEXTAUTH_URL);
    }
}
export const GET = handler;

The button to trigger the sign out (anywhere within the app)

//app/components/signoutlink
'use client'

export function SignOutLink() {    
    return (
        <div>
            <div>
                <button
                    onClick={async () => {
                        // @ts-ignore
                        window.location.href = `${process.env.NEXT_PUBLIC_NEXTAUTH_URL}/api/singlesignout`;
                    }}
                    className={'text-gray-700 block w-full px-4 py-2 text-left text-sm'
                    }
                >
                    Sign out
                </button>
            </div>
        </div>
    )
}

The sign out page

'use client'

import {signOut} from "next-auth/react";
import {useEffect} from "react";

export default function Page() {
    useEffect(() => {
        void signOut({
            callbackUrl: "/signin",
        });
    }, []);

    return <p>Logging out...</p>;
}

//middleware.ts

import { withAuth } from "next-auth/middleware";
import exp from "constants";

export default withAuth({
    pages: {
        signIn: '/signin',
    },
    callbacks: {
        authorized({ token, req }) {
            return token != null 
                || req.url.toLowerCase().includes("singlesignout")
                || req.url.toLowerCase().includes("signin")
                || req.url.toLowerCase().includes("signout");
        }
    }
});

[BradNut]

@maestroAlfredo Have you tried updating your solution in Next 14 and NextAuth Beta v5 yet? Just wondering as I am trying to do the same.

[OlgaOchichenko]

The problem occurs if more than three tabs are open at the same time. The user will log out of the system on one of them, and in this case the token remains in the cookies and a constant re-rendering of the page begins

[gaokevin1]

In our sample app, we've implemented federated sign out the following way:

First, fetch the federated-signout API when you click a Sign Out button somewhere on a client side page. Within this, you have another async fetch that will log the user out of the OIDC provider (in our case Descope). The reason for the order is so that the id_token_hint that's required by the OAuth standard is accessible from the getServerSession() function in the API. There is a .then() after the fetch is complete to then sign the user out their "NextAuth" session, only after they've been signed out of their Descope session.

Sign out button (.tsx): https://github.com/descope/nextjs-hackathon-template/blob/main/app/dashboard/_components/Header.tsx#L16

How the federated sign out process works (for Descope specifically, but would be similar to other providers as well), in the API:
https://github.com/descope/nextjs-hackathon-template/blob/main/app/api/auth/federated-sign-out/route.ts

[shiva-hack]

A simple solution for a federated logout is to add the logout uri to next.config.js

redirects: async () => {
    return [
      {
        source: "/api/sso/logout",
        destination: env.COGNITO_LOGOUT_URL, // the logout url from the sso provider
        permanent: false,
      },
    ];
  },

and then call the signOut function using the callback url:

signOut({ callbackUrl: '/api/sso/logout' })

[rjwignar]

I'm trying this out for my own project.
I'm assuming destination would resemble something like https://mydomain.auth.us-east-1.amazoncognito.com/logout?.
But what would source be? The sign out URL(s) I defined in my Cognito user pool?

When I try out your solution I receive the error Required String parameter 'client_id' is not present after clicking my Logout button, but that's an issue on my end.

Your solution still logs me out of the user pool, as I've confirmed after refreshing that clicking the Login button prompts reauthentication. Thank you.

[rjwignar]

Turns out my destination/logout url was incomplete.
I was missing some request parameters.

This is how I put together my COGNITO_LOGOUT_URL:

  redirects: async () => {
    return [
      {
        source: "/logout",
        destination: `${process.env.AWS_COGNITO_HOSTED_UI_DOMAIN}/logout?client_id=${process.env.AWS_COGNITO_CLIENT_ID}&logout_uri=${process.env.OAUTH_SIGN_OUT_REDIRECT_URL}&redirect_uri=${process.env.OAUTH_SIGN_IN_REDIRECT_URL}&response_type=code`,
        permanent: false,
      },
    ];
  },

Where:

• client_id is the Client App ID (a 26-char alphanumeric string)
• logout_uri is one of the allowed sign-out URLs you configured in your user pool
• redirect_uri is the allowed callback URL you configured in your user pool (OAUTH_SIGN_IN_REDIRECT_URL in my case)

More information can be found in the AWS /logout endpoint document: https://docs.aws.amazon.com/cognito/latest/developerguide/logout-endpoint.html

[alaksana96]

@rjwignar, your suggestion worked for me with Cognito! Its been bothering me for quite a while, so thank you so much!

I feel like this should be added to the Cognito configuration page
https://next-auth.js.org/providers/cognito#configuration

[amjedidiah]

@rjwignar
Same as @alaksana96 said

Been bugging me for weeks now.
But your solution worked fined.

Thanks

[markodvornik]

Working example with Keycloak, App Router, and NextAuth v5.

    "next": "^14.1.0",
    "next-auth": "beta",

Keycloak

• see your https://<KEYCLOAK_SERVER>/realms/<REALM>/.well-known/openid-configuration for Logout URL (under end_session_endpoint)
• Keycloak Logout endpoint requres a http POST method invocation, x-www-form-urlencoded payload with the client_id, client_secret (if access type is confidential) and the refresh_token.

src/components/SignOut.tsx

• Server component SignOut passes session data (refreshToken) to server form action (federated-sign-out).
• signOut() is using default redirect.

import { signOut } from "../../auth";

export function SignOut({ refreshToken }: { refreshToken: string }) {
  return (
    <form
      action={async () => {
        "use server";
        try {
          await fetch("http://localhost:3000/api/auth/federated-sign-out", {
            headers: {
              refresh_token: refreshToken,
            },
          });
        } catch (error) {
          console.error("Error during sign out:", error);
        }

        await signOut();
      }}
    >
      <button>Sign Out</button>
    </form>
  );
}

app/api/auth/federated-sign-out/route.ts

Keycloak client is not configured with confidential access type, using only client_id & refresh_token

import { NextRequest, NextResponse } from "next/server";

export async function GET(req: NextRequest, res: NextResponse) {
  try {
    const refreshToken = req.headers.get("refresh_token");

    if (
      !refreshToken ||
      !process.env.AUTH_KEYCLOAK_END_SESSION_ENDPOINT ||
      !process.env.AUTH_KEYCLOAK_ID
    ) {
       throw Error;
    }

    const body = `client_id=${process.env.AUTH_KEYCLOAK_ID}&refresh_token=${refreshToken}`;

    const endSession = await fetch(
      process.env.AUTH_KEYCLOAK_END_SESSION_ENDPOINT,
      {
        method: "POST",
        headers: {
          "Content-Type": "application/x-www-form-urlencoded;charset=UTF-8",
        },
        body,
      }
    );

    if (endSession && endSession.status && endSession.status >= 300) {
      console.warn("END_SESSION ERROR", endSession.status);
      throw Error;
    }

    return NextResponse.json({ success: true });
  } catch (error) {
    return NextResponse.json({
      success: false,
      message: "Error Sign out",
    });
  }
}

[peppescg]

Hi @markodvornik how your solution clean the cookies session?
I received 200 from logout keycloak, but the cookies session are still there, so I am wondering if I missing something

So my goal is to have a custom SignOut page, that needs to call manually the fetch signout, usually without the custom solution
the below session will be clean after called signOut, in my custom use case nope.

next-auth.session-token.0
next-auth.session-token.1

[Renkas]

Are there any plans to actually add federated logout to the library?

[Jdruwe]

Is there an issue calling signOut from inside an API route handler? I want to call the end_session_endpoint first passing my API route handler as a callback.

[theogravity]

For those using FusionAuth with nextauth 5:

// app/api/auth/federated-logout/route.ts

import { auth } from "@/auth";
import { serverEnvs } from "@/config/constants.server";
import { getLogger } from "@/utils/logger";
import { cookies } from "next/headers";
import { NextResponse } from "next/server";

const clearCookieOptions = "Max-Age=-1; Path=/; Secure; HttpOnly; SameSite=None;";

// https://github.com/nextauthjs/next-auth/discussions/3938#discussioncomment-8799241
// https://github.com/nextauthjs/next-auth/discussions/3938#discussioncomment-7791235
/**
 * Signs the user out from both FusionAuth and the application
 */
export async function GET() {
  const session = await auth();
  const log = getLogger().withPrefix("[auth]");
  try {
    log.info("Signing out from FusionAuth...");
    const endSessionURL = `${serverEnvs.FUSIONAUTH_URL}/oauth2/logout`;
    await fetch(endSessionURL, {
      method: "POST",
      headers: {
        "content-type": "application/json;charset=UTF-8",
      },
      body: JSON.stringify({
        client_id: serverEnvs.FUSIONAUTH_CLIENT_ID,
        client_secret: serverEnvs.FUSIONAUTH_CLIENT_SECRET,
        id_token_hint: session.token.idToken,
        tenantId: serverEnvs.FUSIONAUTH_TENANT_ID,
      }),
    });

    // Clear all cookies
    log.info("Clearing application cookies...");
    let setCookies = "";
    for (const cookie of cookies().getAll()) {
      // Need to keep this cookie for passkey usage
      if (!cookie.name.startsWith("fusionauth.webauthn-reauth")) {
        setCookies += `${cookie.name}=; ${clearCookieOptions}`;
        cookies().set(cookie.name, "", {
          path: "/",
          maxAge: -1,
          secure: true,
          sameSite: "none",
        });
        cookies().delete(cookie.name);
      }
    }

    cookies().set("next-auth.session-token", "", {
      path: "/",
      maxAge: -1,
      secure: true,
      sameSite: "none",
    });
    cookies().set("__Secure-next-auth.session-token", "", {
      path: "/",
      maxAge: -1,
      secure: true,
      sameSite: "none",
    });

    setCookies += "next-auth.session-token=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure; SameSite=None;";
    setCookies += "__Secure-next-auth.session-token=deleted; path=/; Secure; expires=Thu, 01 Jan 1970 00:00:00 GMT";

    return new Response(JSON.stringify({ ok: true }), {
      status: 200,
      headers: {
        "Set-Cookie": setCookies,
        "Content-Type": "application/json",
      },
    });
  } catch (error) {
    return NextResponse.json({
      success: false,
      message: "Error Sign out",
    });
  }
}

Then apply in your component:

"use client";
import { useSession } from "next-auth/react";
import { useCallback } from "react";

export default function UserMenu() {
  const { data } = useSession();

  const handleSignOut = useCallback(() => {
    fetch("/api/auth/federated-logout")
      .then((res) => {
        return res.json();
      })
      .then(() => {
        window.location.href = "/";
      })
      .catch((e) => {
        getLogger().withError(e).error("Failed to sign out");
      });
  }, []);

  ...
}

[theogravity]

I found this doesn't work when the auth server (eg fusion auth) is on a different subdomain. I have a simplified approach here.

This is using next.js app router.

Create app/sign-out/page.tsx
Create components/SignOutComponent.tsx (or wherever you store your components)

import dynamic from "next/dynamic";

const SignOutComponent = dynamic(() => import("@/components/SignOutComponent"), {
  ssr: false,
});

export default function SignOutPage() {
  // We need to use the dynamic import here to prevent the component from being rendered server-side
  // because if we do we get annoying hydration errors we don't care about
  return <SignOutComponent />;
}

// SignOutComponent.tsx
"use client";
import Cookies from "js-cookie";
import { signOut } from "next-auth/react";
import { useCallback } from "react";

const SIGN_OUT_INIT_COOKIE_NAME = 'sign-out-init';

// You can create a cookie, store in local storage, etc, it's just a thing that informs us that the user 
// is coming from the fusion auth sign out redirect
const isSignOutInit = Cookies.get(SIGN_OUT_INIT_COOKIE_NAME);

/**
 * Signs the user out of the application (session = cookies means the same thing):
 * 1. Sets a cookie to indicate that the sign-out process has started
 * 2. Redirects to FusionAuth to sign out
 * 3. FusionAuth clears its SSO cookies, then redirects back to this page
 *   - This is important because if the SSO cookies aren't cleared, then the user will be signed back in automatically
 *   if the only application session is cleared.
 * 4. Checks for the cookie set in step 1 to then call the signOut function from next-auth
 *   to clear the application session
 * 5. Redirects to the application root
 * 6. middleware.ts detects the missing application session and redirects to the FusionAuth sign-in page
 */
export default function SignOutComponent() {
  const handleSignOut = useCallback(async () => {
    Cookies.set(SIGN_OUT_INIT_COOKIE_NAME, "1", {
      secure: true,
      sameSite: "Strict",
    });

    // currentDomain needs to be added as part of the "Authorized Redirect URLs" in Fusion Auth
    // or you'll get an error around post_logout_redirect_uri
    const currentDomain = encodeURIComponent(`${window.location.origin}/sign-out`);
    // Sign out from FusionAuth
    // FA will redirect to the sign-out app page to complete the sign-out
    window.location.href =
      `${<URL TO FUSION AUTH>}/oauth2/logout?` +
      `client_id=${encodeURIComponent(<FUSION AUTH CLIENT ID>)}` +
      `&tenantId=${encodeURIComponent(<FUSION AUTH TENANT ID>)}` +
      `&post_logout_redirect_uri=${currentDomain}`;
  }, []);

  useAsyncEffect(async () => {
    if (!isSignOutInit) {
      await handleSignOut();
      return;
    }

    Cookies.remove(SIGN_OUT_INIT_COOKIE_NAME);

    await signOut({
      // This goes to the app root, but middleware.ts will redirect to the sign-in page on FusionAuth
      redirectTo: "/",
    });
  }, []);

  if (!isSignOutInit) {
    // We don't want to render anything initially because the redirect to fusion auth is a blank page
    // so it would look jarring to see the page content for a split second before the redirect
    return null;
  }

  return <div>Some sign out message that you are signing out</div>
}

Calling /sign-out should then sign you out.