How should I handle stale JWT group claims when permissions change mid-session?

Use short-lived access tokens together with a longer-lived refresh token. When the access token is close to expiring, refresh it so the client can receive updated claims without requiring a logout. A pre-token-generation trigger can inject the current group data when Cognito issues the replacement token. This is especially useful if the client knows a membership-changing action just occurred and can trigger a refresh immediately.

For sensitive operations, check authorization against a current server-side record on every request or at least for high-impact actions. You can cache group membership briefly in DynamoDB or Redis and invalidate that cache when memberships change. A revocation or authorization-version field can also let the backend reject tokens issued before a known change.

There is no way to make an already-issued JWT change in place. You either issue a new token or perform authorization outside the token. A practical setup is to force a refresh after known membership changes, use a short access-token lifetime for changes made elsewhere, and keep a backend lookup for operations where a stale permission would be unacceptable.

Treat the groups in the JWT as a cached hint rather than the ultimate authorization source. Use the token mainly to establish identity, then resolve account permissions on the backend from Cognito or, preferably, your own authorization store. A short server-side cache can keep this fast. Short-lived access tokens reduce the stale window, but they cannot guarantee that a permission change takes effect immediately.