How to invalidate jwt issued before deativating user?

[bharath.yadavally]

@dan

Can you be able to help me understand these flows:

I have two users parent-user and child-user

1. child-user logged in and received a valid token with lengthy expiry

2. parent-user deactivated child-user using endpoint DELETE: /api/user which successfully locked the user and showing locked in fusionauth UI

3. But, when child-user requested data using token issued in step 1, validate endpoint GET: api/jwt/validate endpoint is not invalidating the user. And returning success response back. When i checked user, applications are present in registrations.

Is this a bug? How can i invalidate a locked user properly??

EDIT:

I have looked into your post: https://fusionauth.io/community/forum/topic/49/how-should-i-validate-access-tokens

And, make sense /api/jwt/validate is just validating expiry, signature and claims. But, when I hit /oauth2/introspect endpoint I am still getting user status active

{
	"active": true,
	"applicationId": "<appid-uuid>",
	"aud": "<appid-uuid>",
	"auth_time": 1673234995,
	"authenticationType": "PASSWORD",
	"email": "myuser@mailinator.com",
	"email_verified": true,
	"exp": 1674444595,
	"iat": 1673234995,
	"iss": "auth-dev.mailinator.com",
	"jti": "jti-uuid",
	"roles": [],
	"scope": "offline_access",
	"sub": "<user-uuid>",
	"tid": "<t-uuid>"
}

[dan]

@bharath-yadavally If you are passing the access token to the introspect endpoint, you'll continue to get active because the access token is still active.

Are you trying to figure out how to have the access token revoked if the user account is deactivated? Or how to have the refresh token revoked?

[bharath.yadavally]

@dan I am passing the access token to the introspect endpoint, as you mentioned it is always returning active.

What I actually trying to do is to have the access token revoked if the user account is deactivated.

For my scenario, I am using access token with longer expiry but also wanted to revoke those token if a user is deactivated before that token is expired.

[dan]

@bharath-yadavally In that case, I'd probably pursue a similar webhook strategy to the one outlined here where you listen for a deactivation event in your services.

When that happens, add the user id to a redis database. Then, whenever you receive a JWT, check the subject claim against this redis database. If the user exists there, they've been deactivated and the request should fail.

[bharath.yadavally]

@dan
Okay I can give it a go.

But, trying to understand what is the difference in doing this webhook way vs doing following steps:

On every client request to backend service:

1. Call GET: api/jwt/validate or can implement manual validations (when no-claims scenario, only need to check signature and expiry)
2. Call GET api/user with valid jwt from step 1. Which returns a response with user.active: false for deactivated user

[dan]

@bharath-yadavally You could absolutely use the 2 step approach you outlined. There are two different approaches that have different strengths and weaknesses.

The tradeoffs are that if you make those two calls, you're depending on the identity provider to be up and available to your backend service. You're tightly coupling the backend service to the identity provider.

That can work fine, but as you scale, more and more backend services will be making those calls, and the idp and speedy connections to it become more and more critical to your application.

Contrast that with the webhook approach, where the data is pushed to every backend service, and only when a user is deactivated. In this case, there'll be far less coupling with the identity provider, at the cost of more complexity on the backend service side.

Hope that helps.