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>

[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.

[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;
    },
}

[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 a@google.com.
2. Logout
3. Log in with b@google.com
4. Next auth thinks you logged in with a@google.com

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 a@google.com.
2. Logout
3. Log in with b@google.com
4. Next auth thinks you logged in with a@google.com

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.

[alessandrojcm]

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

Alright thanks, but that'll mean the app would "flash" back briefly to then redirect to the login page since signOut is part of the client-side API; unless I manually remove the cookies from the server-side, am I correct?

[alessandrojcm]

Yeah, so when you land on your logout page, you will also have to call the signOut method, because the session cookie cannot be removed by your Provider with front-channel logout, since it is probably on a different domain.

Hey, thanks for the answer. Yes that's is what we're doing on the /logout page.

[balazsorban44]

are you actually redirected to the OAuth provider when calling the federated logout endpoint? and how do you invoke that?

Remember to initiate the logout, you will need something like

window.location.href = "/api/federated-logout"

I'm not really familiar with fusion auth, but you should be seeing some kind of a spinner (calling front, channel logout endpoints in iframes or similar) which then at the end redirects you back to your logout page on you site.

If you don't hit the fusionauth endsession endpoint, then you will never be logged out from your provider

[alessandrojcm]

Yes, that's exactly what I'm doing, using window.location.href = "/api/federated-logout then it redirects to FusionAuth where I can see the loading screen for the logout route, then back to the app on the /logout route which calls signOut inside an useEffect and then back to the /login screens which call signIn and should redirect to the FusionAuth /oauth2/authorize screen but instead it gets back to the app as if the session was still valid. FusionAuth is fully OIDC compliant so this in theory should work.

[balazsorban44]

back to the /login screens which call signIn and should redirect to the FusionAuth

so the sign-in is automatic as well, using a useEffect?

If you stop it and just visit your FusionAuth account page after you initiated a logout, is the user logged in still on FusionAuth? That would indicate that the Provider wasn't able to log the user out for some reason. 🤔

[alessandrojcm]

back to the /login screens which call signIn and should redirect to the FusionAuth

so the sign-in is automatic as well, using a useEffect?

Yes that's correct, the app is a dashboard so there's nothing to show unless the user is logged in.

If you stop it and just visit your FusionAuth account page after you initiated a logout, is the user logged in still on FusionAuth? That would indicate that the Provider wasn't able to log the user out for some reason. 🤔

Actually I didn't check that, I'll do that tomorrow and report back.

[balazsorban44]

Depending on your requirements, I would say the UX of logging out, then being redirected back to the login screen only to be redirected to FusionAuth again is a bit confusing IMO. Why not just stop at the logged-out screen, where you can present a login button for manual action for the user?

[alessandrojcm]

Depending on your requirements, I would say the UX of logging out, then being redirected back to the login screen only to be redirected to FusionAuth again is a bit confusing IMO. Why not just stop at the logged-out screen, where you can present a login button for manual action for the user?

Yeah, it's kinda confusing; we're still trying to iron out the UX side, this sounds like a good idea tho, I'll discuss it with the team!

[alessandrojcm]

If you stop it and just visit your FusionAuth account page after you initiated a logout, is the user logged in still on FusionAuth? That would indicate that the Provider wasn't able to log the user out for some reason. thinking

So reporting back on this, when the error happens, if I go to FusionAuth's login page directly the user is indeed logged out.

[balazsorban44]

I am all the more curious, how is the user logged in again on FusionAuth when they are redirected /logout -> /login -> FusionAuth login? 👀 😅

UPDATE:

Re-reading this

should redirect to the FusionAuth /oauth2/authorize screen but instead, it gets back to the app as if the session was still valid.

means you don't actually get redirected back to FusionAuth, huh? 🤔 So for some reason, the signOut call did not remove the session cookie correctly.

The problem will be with signOut. Could you share with me how your /logout page looks like, how do you invoke signOut?

One idea that comes to mind is using redirect: false and awaiting the sign-out process, and do the redirection after that:

https://next-auth.js.org/getting-started/client#using-the-redirect-false-option-1

[alessandrojcm]

I am all the more curious, how is the user logged in again on FusionAuth when they are redirected /logout -> /login -> FusionAuth login? eyes sweat_smile

UPDATE:

Re-reading this

should redirect to the FusionAuth /oauth2/authorize screen but instead, it gets back to the app as if the session was still valid.

means you don't actually get redirected back to FusionAuth, huh? thinking So for some reason, the signOut call did not remove the session cookie correctly.

The problem will be with signOut. Could you share with me how your /logout page looks like, how do you invoke signOut?

One idea that comes to mind is using redirect: false and awaiting the sign-out process, and do the redirection after that:

https://next-auth.js.org/getting-started/client#using-the-redirect-false-option-1

Yes these are my thoughts exactly, signOut is invoked inside an useEffect on mount; pretty much

signOut({ callback: '/login' }).then(() => {
    // some cleanup
});

But I just changed it to this:

signOut({ redirect: false }).then(() => {
    // some cleanup and enabling sign in button here
});

And added a button that calls singIn instead of redirecting automatically. Will test and report back.

[balazsorban44]

I would do (if using .then)

signOut({ redirect: false, callbackUrl: "/login" }).then(({ url }) => {
  router.push(url)
});

or

await signOut({ redirect: false })
router.push("/login")

This might be the problem, since without redirect: false, the promise won't do anything.

If the session is still "stuck" for some reason, doing window.location.href = "/login" would be a better option that will reset any stale state. Might be OK after a logout anyway.

[alessandrojcm]

Cool thank you very much for your help @balazsorban44! The latest changes appear to have fixed the issue. Nervetheless, we sometimes face the issue described in #1367 when calling signIn just after signOut; will check that issue instead. Thanks again!

[balazsorban44]

make sure you have at least 3.27.3 installed, I think we fixed a related bug then!

https://github.com/nextauthjs/next-auth/releases/tag/v3.27.3

[ngoc199]

I am using 4.0.2 but this problem still happens.

I am using Next-Auth with FusionAuth as Identity Provider.

I have used the above comments to sign out like this.

const data = await signOut({ redirect: false });
router.push(data.url);
window.location.href = "/";

But after that, even after I refresh the page, the signIn will still log the previous user in.

I have to manually delete the cookies after signing out to make the login form appear again.

Is there any way to fix this problem now?

[alessandrojcm]

Hi @ngoc199, I had the same problem; this happens because FusionAuth uses SSO, so logging you from your Next app does not log you out from the FusionAuth SSO. You need to redirect to this endpoint to effectively log the user out from SSO. This is how I solved it:

• Create and API route (ie /api/auth/global-logout) to redirect the user to when they log out (this will be done with window.location.href = /api/auth/global-logout). That API route will build the appropriate URL as pointed out on the FusionAuth docs above
• That URL needs contain a post_logout_redirect_uri to your Next app (ie /logout) which will call signOut.

That way you will be logged out from both the SSO and your app.

To summarize: API route that builds the logout URL as per the docs I linked, redirect your user to that API route, FusionAuth redirects you back to the post_logout_redirect_uri and that page on your app must call signOut. It's not an ideal UX I know, but if you match the FusionAuth theme with the look & feel of your app and add a nice logout animation the users won't notice that much.

Hope that helped.

[yuriy-eleks]

@ngoc199 That's because your provider still has your session (there is nothing related to next-auth)

basically you have two sessions (one in your application, and another in provider's application)

1. next-auth session
2. auth2 provider session

when you are logging out from next-auth (signOut) next-auth removes own session NOT provider's session

I can show example that we're using, we have OKTA as provider

logout process:

first you need to go on your provider and logout there, how to do it depend on your provider's api

for example in okta it's

https://${ENV.OKTA_DOMAIN}/oauth2/${ENV.OKTA_AUTHORIZATION_SERVER_ID}/v1/logout?id_token_hint=${session.idToken}&post_logout_redirect_uri=${ENV.NEXT_PUBLIC_CORE_SITE_URL}/signout

then provider redirect you to post_logout_redirect_uri same flow as login, and after that you can signOut from next-auth

done!

BR

[medarma86]

@yuriy-eleks I have tried this but still the session is not getting cleared after logout. Do you think if any more other settings that I need to tk cr to make it??

[ngoc199]

@medarma86 You have to try using @alessandrojcm solution. It works for me.

[medarma86]

@ngoc199 issue is with the signout url defined in okta dev configuration. I have done the following steps and it's working fine now.

1. Making sure the post_logout_redirect_uri value is same as the logout url in okta dev configuration.
2. Used window.href to redirect to https://${ENV.OKTA_DOMAIN}/oauth2/${ENV.OKTA_AUTHORIZATION_SERVER_ID}/v1/logout?id_token_hint=${session.idToken}&post_logout_redirect_uri=${ENV.NEXT_PUBLIC_CORE_SITE_URL} after signing out like below.
   onClick={async (e) => {
   e.preventDefault()
   await signOut()
   window.location.href= https://${process.env.NEXT_PUBLIC_OKTA_ISSUER}/v1/logout?id_token_hint=${idToken}&post_logout_redirect_uri=${process.env.NEXT_PUBLIC_NEXTAUTH_URL};
   }}

[ryanmr]

My product users had trouble logging out to switch among their accounts.

On my product, I use Auth0 in conjunction with Next Auth. My solution below is based on alessandrojcm's suggestion above.

function handleSignOut() {
  const clientId = process.env.NEXT_PUBLIC_AUTH_CLIENT_ID;
  const signoutRedirectUrl = process.env.NEXT_PUBLIC_AUTH_SIGNOUT_REDIRECT_URL;
  window.location.href = `https://auth.example.com/v2/logout?client_id=${clientId}&returnTo=${encodeURIComponent(
    signoutRedirectUrl
  )}`;
}

This step logs me out of Auth0 IDP.

Then where NEXT_PUBLIC_AUTH_SIGNOUT_REDIRECT_URL is pointed, I have it trigger the nextauth signout with a callback that is set to window.location.origin, so users are brought back to the website root after logout.

export default function SignoutPage() {
  useEffect(() => {
    setTimeout(() => {
      signOut({ callbackUrl: window.location.origin });
    }, 1000);
  }, []);

  return <Loading text="Please wait while we sign you out!" />;
}

This step logs me out of the app by ending the session.

It would be great to have this integrated into nextauth, but this solution works well for now.

[GrzegorzCzm]

Hi,

I have applied your suggestions and it work quite nice with federated-logout. But now I am struggling with next thing. When user is logged in, close the page and open it again then still will be logged in. This is fine when during login process user mark checkbox 'remember me'. But any idea how we can handle use-case when user should not be remembered after closing the page?
I am using "next-auth": "^4.0.5"

@balazsorban44 or anyone? Do you have an idea how to overcome this issue?

[balazsorban44]

The session expires after the specified amount of time, if the user does not interact with the site before that. You can override this, please refer to the docs.

Session as expiry is not supported, as for example Chrome does not respect that anyway. There's a related issue about that, you can search it up for the explanation.