How do you handle stale group claims in Cognito tokens?

For permissions that need to change mid-session, I'd use the JWT to establish identity and look up account access on the backend. That lookup could be against your own authorization store or another source that actually receives the group changes.

A short server-side cache can keep the lookup from becoming expensive. Its lifetime becomes part of your revocation delay, so pick it based on how long you're willing to let removed access remain valid. Make the check on operations as well as on the account list.

Claims in a JWT aren't inherently the wrong place for authorization. They are a snapshot, and token expiry puts a limit on how long that snapshot is used. Short-lived tokens can be a reasonable tradeoff if a delay in removing access is acceptable.

The catch here is that issuing a new token only helps if the claims are rebuilt from current data. Refreshing a token while reusing a stale custom attribute won't solve the underlying problem.

Look at Cognito's pre-token generation trigger. It can modify claims when tokens are generated, including during refresh. The trigger would need a way to fetch current group membership rather than just copying the existing custom attribute.

You'll still need a refresh strategy. Until the client gets a new token, the old claim remains a snapshot. You could refresh on a short schedule or signal the client when membership changes, depending on how quickly access needs to change.

Watch the boundary between Cognito and the upstream identity provider. If Cognito gets groups from a federated login, a Cognito refresh doesn't necessarily mean the upstream provider has supplied fresh groups. Figure out where the current membership can be queried and how it gets into your authorization decision before relying on any refresh flow.