Suspending a Kinde user leaves their agent's signed token verifying mid-task

An OAuth access token is a small JSON payload with a cryptographic signature attached, and whatever checks it verifies that signature against a public key instead of calling the issuer to ask whether the token is still good ^[5]. An API can confirm a token is genuine without a database round trip on every request ^[6]. Suspending a user in Kinde changes a row in Kinde's own database, and the token was already signed and handed out before that write, so it verifies exactly as it did before ^[3].

The author, who publishes as sholajegede, wrote: "So that gap isn't a bug in Kinde, and it isn't a bug in OAuth either." ^[8] I think that is right. A stateless credential stays valid until whatever expiry it was minted with ^[17], and revoking one properly means tracking every issued token in a lookup table, the thing signed tokens exist to avoid, or waiting for the token to expire on its own ^[7].

The enforcement point in the demo app is a single function, enforceToolCall, which looks up the acting user's current status for every tool call the model makes ^[13]. The agent is a Claude Messages API loop with three tools against a demo set of internal resources: list_resources, read_resource and write_resource ^[10]. The registry marks write_resource as destructive: true and the other two as destructive: false ^[11], so two of the three registered actions are reads ^[16].

Both the tool schema handed to Claude and the enforcement check are built from the same registry ^[12], so the list the model is offered and the list the check knows about cannot drift apart. An action that is not in the table cannot be called by accident ^[14].

Whether this transfers depends on where you put the check. It has to sit on the path every tool call takes, because a long-running agent passes through session setup once and then loops; a check at the top of the loop reads a status that was fresh minutes ago. It also depends on delivery: the app's record only stops saying "active" once Kinde's webhook arrives ^[9]. Both conditions are properties of your own code.

The post says it reports webhook deliveries measured live, a production bug that could have left an offboarded user's record looking active forever, and a hard number for how long an offboarded person's agent keeps acting before anything catches it ^[15]. The text available stops at the enforcement function, before those figures. On the evidence here, the window is bounded by the token's minted expiry ^[17].