Handling Suspended User Logout in NextJS App

Two options

1. Call the /introspection endpoint to validate the token when performing critical actions
2. reduce the lifespan of the access_token to its refreshed more frequently

If I use the introspection API as part of my Auth guard checks, do you know what type of performance impacts this may have. Essentially do you have any API benchmarks

We could look at implementing a webhook if this is something you'd be interested in using?

What would that flow look like if we used a webhook. I know the webhook triggers if the user is suspended already

I think you could do something like this:

• user is suspended via ui / api, I believe this should already end any active sessions for the user on the Kinde side
• Kinde sends a webhook request (user.updated with is_suspended flag)
• On your callback url check if the user is suspended
• In your application call the logout function to destroy local cookies or you could handle cookie / session termination yourself to avoid redirects. Redirect the user appropriately.

This would require some sort of socket between our BE and FE which we haven't created the architecture for.

Could this be something added to the refreshToken function? As this token is still refreshed even if the user is suspended

I see, I'm surprised that it does this, we'll look into it

That would be great, as I refresh to token on refresh etc anyway incase the users account information has changed. So if this has a chance of triggering a logout if failed that would be the ideal solution

Could this be something added to the refreshToken function? As this token is still refreshed even if the user is suspended
I've just run some tests (on postman directly to the endpoints rather than via an SDK) and attempting to use a refreshToken on a suspended user returns the following:

Error: invalid_grant, Description: The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.

So I am using the refreshToken sdk in the NextJS package. I refresh my token on refresh of the app to make sure the users claims are up to date. I'd expect that if the token is invalid to either be logged out or at least provide me with an error but it doesn't seem like it does and I just get the token returned

If I pass that token to the introspect api myself it gives me an error

I see, presumably that's still the original token then? I.e. the expiry or jti claims don't change?

Yeah just reviewed that. The token is the same

OK thanks, sounds like we may need an update to the SDK then, my colleague would probably be the best person to look a this, he's on leave until Wednesday but I can discuss this change with him then.

Do you have any benchmarks on the introspect api? Do you have more information about what this checks also? As it might be worth me using this to validate my tokens anyway. My concern would be performance

The introspect endpoint should validate the token and check if it is still active, you would receive a response similar to this:

{
    "active": true,
    "client_id": "abc123",
    "exp": 1719314881,
    "iat": 1719228481,
    "scope": "openid offline",
    "sub": "kp_abc123",
    "username": "kp_abc123"
}

No worries, i'll catch up with when he returns

I ran some checks against our logs regarding processing times for the introspection, I can see you've made some requests to that endpoint already. In the UK region you're averaging around 34ms for the requests to process, there's only a handful of occurrences that exceeded 100ms in the past week. Similar results in the EU region for other customers.
We also have throttling in place for high levels of requests, there's not a fixed number for this but it's 1000's per minute and can be adjusted for an individual business if required.

Yeah so I am using the introspect api on an verification check to work round the issue of not being able to handle suspended users on the FE. This check only happens once per refresh of page. So technically, there is a short period of time, we a user may have been suspended during their active session that I am trying to mitigate as much as possible due to the data we store. Can get more into the specifics if required but will be in a different channel