Trouble terminating Auth0 user session


I can’t get the OIDC /Logout endpoint to log users out of their Auth0 session.

My app’s overall architecture is that it has a React front-end that calls a Node.js back-end server (called server.js) which has API endpoints that the front-end calls to log in, fetch user data, and log out; server.js then interacts with Auth0 to obtain tokens and get user info.

My logout functionality is implemented as follows: in the user’s profile page is a logout button which, when pressed, calls server.js’s /logout endpoint, while sending it the access and ID tokens that are stored in the localStorage of the browser.

server.js uses the ID token to implement the logout URL per the Use the OIDC Endpoint to Log Users Out of Auth0 article.

The ID token was originally retrieved when the user signed in as follows (ROPF flow):

const { AuthenticationClient } = require('auth0');

const auth0AuthClient = new AuthenticationClient({
  domain: AUTH0_DOMAIN,
  clientId: AUTH0_CLIENT_ID,
  clientSecret: AUTH0_CLIENT_SECRET,

// ...

    const tokenResponse = await auth0AuthClient.oauth.passwordGrant({
      audience: MY_AUDIENCE_URL,
      scope: 'openid',

    const idToken =;

I then build my logout URL as follows:

const auth0LogoutUrl = `https://${AUTH0_DOMAIN}/oidc/logout?id_token_hint=${idToken}&post_logout_redirect_uri=${LOGOUT_REDIRECT_URL}`;

=> PROBLEM: While I get a HTTP 200 “OK” response when server.js GETs the logout URL, I noticed that the application’s logs (from the Auth0 dashboard) had “N/A” as a value in the User field of the logout event (see screenshot below).

This leads me to believe that the user’s Auth0 session was not terminated. Per the Use the OIDC Endpoint to Log Users Out of Auth0 article:

The attached ID token contains the registered claims issuer (iss), audience (aud), and the Auth0 session ID (sid) for verification.

When looking at my ID token’s payload, there is no sid value:

  nickname: 'test',
  name: 'test',
  picture: '',
  updated_at: '2023-10-11T17:04:43.919Z',
  email: '',
  email_verified: true,
  iss: '',
  aud: '...',
  iat: 1697043883,
  exp: 1697079883,
  sub: 'auth0|...'

1) Is there no user associated with the logout event because my ID Token has no sid claim? 2) How do I add the sid claim to my ID Token if that is what will successfully terminate the user’s Auth0 session?

Any and all help would be appreciated!

Hey there @kalashikov !

What about a successful login event? Can you see any in your Auth0 dashboard logs section?

It looks like there is no common context needed to link the login and logout event with the user.

Can you please try toggling the “ID Token Claims Mapping” in the settings section of the app in question (in the Auth0 dashboard).

On the other hand, adding custom claims to the id token can be done with actions - Actions Triggers: post-login - Event Object

Hi @marcelina.barycka, thanks for answering! Logging in works just fine, the relevant log event is further below.

Can you please try toggling the “ID Token Claims Mapping” in the settings section of the app in question (in the Auth0 dashboard).

Where exactly is the “ID Token Claims Mapping” setting? I went to my dashboard > Applications > [my application] > Settings tab, but there was no such option, even in the “Advanced” section. Would you have a screenshot of where I can find the setting?

Lastly, if there is no context to link the logout event with the user, how does Auth0 know which session to terminate? Seems like attaching the ID token to the logout request (per the article I linked in my original post) was to get the session ID (sid) and thus allow Auth0 to know which session to terminate.

Login event:

Hi @kalashikov ,
After additional investigation, I see that the “ID Token Claims Mapping” is no longer available.

I’m wondering why you have no sid claim in the id token received.

When reviewing my auth0 tenant logs, I can see that the session_id is created and associated with the “success login” event when the /authorize endpoint is called (so when the auth0 login page is utilized).

For the “Success exchange” event the session_id is not available in logs.
I’m not sure but it might be that with your current settings (how you authorize user) it will not work.

To check it from a different angle, could you please try to:
-Change the number of connections available for the app to be only the auth0 database? (since in the token request you are sending credentials for a specific connection) Will you receive the sid?

-Send a curl request to the id token endpoint with the same credentials to see if you receive the sid in the id token?

Hi @marcelina.barycka,

This might be a clue: I don’t actually have any “successful login” events in my log, only a token exchange. Does the auth0AuthClient.oauth.passwordGrant() method I use (per my 1st post) call the /authorize endpoint at all?

I have disabled the only other connection for my app per the screenshot below, leaving only “Username-Password-Authentication”.

Outcome is the same: no SID in the ID Token:

JSONApiResponse {
data: {
created_at: ‘2023-09-04T01:36:26.675Z’,
email: ‘’,
email_verified: true,
identities: [ [Object] ],
name: ‘[…]’,
nickname: ‘test’,
picture: ‘’,
updated_at: ‘2023-10-24T11:42:14.684Z’,
user_id: ‘auth0|6[…]e’,
last_ip: ‘[…]’,
last_login: ‘2023-10-24T11:42:14.684Z’,
logins_count: 105

Please see the output of that below, and note that with a scope of “read:sample” in the request (as per the link you sent me), all I get is the access token as you see below. My implementation using a scope value of ‘openid’ (per my 1st post here) returns the ID token (with no sid).


Does any of this help?

Hey there @kalashikov !

Thank you for following up on this. After double checking, the available documentation mentions about the limited capabilities of the password exchange grant flow and even the prohibition of using this method with auth0 by okta. I think it may be not profitable for you to invest time in exploring it further.

Hi again @marcelina.barycka and thanks for your continued help with this!

To be sure we are talking about the same thing: my intent was to implement ROPF (Resource Owner Password Flow) whereas you are mentioning:

Do these refer to the same thing? If not, am I simply implementing ROPF incorrectly?

If yes, then I will abandon exploring this option and I will go the route of embedding Auth0’s login form into my own login page (as a panel) as I would like users to have the chance to log in the moment they land on my homepage - is that what “Embedded Login” is?

Bump please; @marcelina.barycka are you able to assist with my last question? I’m basically looking to know which implementation direction to go in considering you last answer. Thank you!

Hey there @kalashikov !

Lately I came upon another topic that explored the reason of a session not being started - may serve you as a good reference!

I would like users to have the chance to log in the moment they land on my homepage - is that what “Embedded Login” is?

That’s right. With embedded login a user attempting to authenticate (send credentials) is not redirected to the Auth0 Login page but it happens within your page. Here’s a good starter for this topic - Embedded Login

Thanks and have a good day!

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.