https://descope.com logo
Join Slack
Powered by
Hey, I need urgent help with my descope account, i...
# ask-a-descoper
k
Hey, I need urgent help with my descope account, is there a way to force/bulk invalidate the user logins?
✅ 1
d
Individual User Logout You can force logout individual users using the Management API :
Copy code
curl -X POST "<https://api.descope.com/v1/mgmt/user/logout>"  
  -H "Authorization: Bearer <ProjectId:ManagementKey>"  
  -H "Content-Type: application/json"  
  -d '{"loginId": "<mailto:user@example.com|user@example.com>"}'
Backend SDK Logout All Sessions For individual users, you can invalidate all their sessions using the Backend SDK :
Copy code
const refreshToken = "xxxx"
const resp = await descopeClient.logoutAll(refreshToken);
Bulk Operations Approach Descope doesn't have a single API endpoint to logout all users at once. For bulk invalidation, you would need to: 1. Use the Search Users API to get all active users 2. Loop through each user and call the logout endpoint individually 3. Alternatively, use JWK rotation with revocation for immediate invalidation JWK Rotation for Global Invalidation For urgent situations, you can use JWK key rotation with revocation . In the Descope Console, go to Project Settings → JWK Rotation and select "Rotate and Revoke" - this will force all users to re-login immediately. Since you mentioned this is urgent, the JWK rotation approach would be the fastest way to invalidate all active sessions across your entire project. Delete User's Passkeys | API Reference | Descope Documentation Backend SDK Session Validation | Descope Documentation JWK Rotation | Descope Documentation
k
We have more than 10k users its not feasible
just need to invalidate the DS token
d
You're absolutely right - looping through 10k+ users isn't practical for urgent situations. Immediate Solution: JWK Rotation with Revocation This is your fastest option for bulk invalidation: 1. Go to Descope Console → Project Settings → Security → JWK Rotation 2. Click "Rotate Key" 3. Select "Rotate and Revoke" (not just "Rotate") 4. This immediately invalidates ALL active sessions across your entire project Alternative: Session Inactivity Timeout You can also configure aggressive session timeouts in Project Settings → Session Management to force re-authentication, but JWK revocation is immediate. The JWK rotation approach is specifically designed for security incidents where you need to force all users to re-authenticate immediately, regardless of user count. I'm connecting you with a member of the Descope support team now for additional assistance with your urgent situation.
m
you can disable users;
but DS invalidate is not possible , as its a stateless JWT you can on your app sidem of course block those created before time X
k
Can I connect with you?
Need a real quick help
Our users are being signed it to different user in different tenants
m
@Rahul Rijhwani can you help here
looping in @Doron Sharon for more options to suggest
d
Did you try to rotate and revoke keys as suggested above?
This will invalidate all new refresh attempts. You can also set the refresh duration to be for short periods.
For existing JWTs you need to block at your app level, since these are not passing through us.
k
you need to block at your app level
Can u provide a snippet on how it would look like?
d
Where you validate the jwt?
In the place you validate the jwt you will need to block them
Did you do the rotate and revoke?
k
yes I did rotate and revoke
but I am still able to access our platform
d
Yes because of have existing jwts..
In the place you validate the jwts at your app you should block them
k
gotcha
let me check it out
d
@Rahul Rijhwani please help if needed
Did you mange @Khalil Patiwala?
k
I just reverted a recent httpOnly change that we pushed which seems to have resolved the issue but we are still triaging this
So for some reason there were two DS cookie stored
which causes our login to not work
I ask user to clear cookies and it works
I also reverted the token response methods to use "response body"
image.png
d
You can also logout via the sdk, and the logout clear the cookie
k
for all domain?
d
No, it is something should run on the user session
There is no way to clear cookies from remote
By the way, once you rotate and revoke: 1. Existing DS JWTs will be invalidated after 5-10 minutes, depends on the refresh duration, default is 5-10 minutes 2. Also when calling the validate jwt, it should not accept them since the public keys got rotated, you just need to make sure to clear their cache so you will get new keys
So basically rotate and revoke + wait x minutes will do the work or clear the public keys cache so you will get the new keys and your internal validations of existing jwts will fail and they won’t be able to use these jwts.
k
That make sense, let me get back to you on this
We recently switched our Descope project from client-side token management to "manage tokens in cookies" (httpOnly) mode. Simultaneously, we deployed server-side code to read the 
DS
cookie as a fallback when no 
Authorization
header is present. What happened: After the switch, users who were already logged in started seeing other users' identities -- different name, email, and tenant. This was not a UI bug; the API was returning a completely different user's data. The affected users: • Were logged in with active sessions before we switched to cookie mode • Did NOT log out and log back in -- their sessions were "live" during the mode switch • Did not share browsers with other users The issue resolved immediately after we reverted both the Descope config (back to client-side token management) and our code changes. What we need to understand: 1. When switching from client-side to cookie-based token management, what happens to existing active sessions? Are they migrated, invalidated, or left in a stale state? 2. Does the SDK's session refresh mechanism (using the 
DSR
refresh token) behave differently during or after a mode switch? Could a refresh during the transition issue a 
DS
cookie containing a different user's JWT? 3. Is there a recommended migration path for switching to cookie mode without disrupting active sessions? (e.g., should we force all users to re-authenticate first?) 4. Could 
descopeClient.management.user.loadByUserId('')
(empty string) return a real user instead of an error? We have a code path where a management API failure could result in an empty user ID being passed to this function.
c
@Aditya Arakal @Bhagwanta Yeole - please assist the above
👀 1
b
@Khalil Patiwala Did you given try to rotate key from the descope console project section?
k
yes I have done it and it did invalidate the session but wanted to understand what caused this why!
a
Hey Khalil, When you switch to cookie-based sessions in Descope, the way tokens are stored and read changes completely. Any users who were already logged in don’t get automatically updated, so their sessions can become inconsistent if both header tokens and cookies are being used at the same time. This can lead to identity mix-ups. The safest way to handle this is to reset all active sessions, clear the DS and DSR cookies, and have everyone log in again so everything starts fresh in cookie mode.
k
@Aditya Arakal were there any API errors during 
2026-03-30 10:30-11:30 UTC
?
a
@Khalil Patiwala Can you DM me your Project ID please? Also, please confirm if you are using api.descope.com or your own cname for the base URL when instantiating the SDK.
k
Dming out project id
3 Views
Open in Slack
PreviousNext
Powered by