There are a couple of overlapping layers here.
Access tokens aren’t revocable by default
Access tokens (JWTs) are self-contained. Once issued, they remain valid until they expire unless you implement a custom revocation strategy (such as token blacklisting). FusionAuth covers one approach here:
https://fusionauth.io/articles/tokens/revoking-jwts
So if your access token lifetime is 600 seconds, a disabled user could continue to access APIs until that token expires (up to ~10 minutes) unless you add an additional revocation layer.
FusionAuth sessions are typically independent from the IdP
Once the upstream IdP authenticates the user, FusionAuth generally maintains its own session state. If a user is disabled in the upstream IdP, that does not automatically invalidate FusionAuth sessions or prevent refresh token usage.
So yes, depending on your implementation, a user can potentially continue to operate in FusionAuth even if they are disabled upstream, until you either:
expire/stop honoring their tokens, or
remove/disable the user in FusionAuth, or
enforce additional checks at login/session refresh time.
Options to meet “disabled within 300 seconds” for one customer
If you need disablement to take effect quickly without shortening sessions for everyone, you generally need an integration that pushes the disablement signal into FusionAuth (or into your resource servers).
A. SCIM (best fit when the customer maps cleanly to a tenant)
If your customer can be logically isolated (e.g., “customer A users live in tenant A”), SCIM is a strong option. The customer’s IdP can provision/deprovision users into FusionAuth, and a disable/delete action can remove their FusionAuth access (including sessions). This is the cleanest approach when tenant segmentation is possible.
B. Event-driven deprovisioning (IdP → your service → FusionAuth API)
If the customer’s IdP can emit events (user disabled/deprovisioned), you can build a lightweight integration that:
receives the IdP event, then
disables or deletes the corresponding user in FusionAuth via API.
Once the user is disabled/deleted in FusionAuth, they won’t be able to continue normal authentication flows.
C. Token revocation strategy (resource server enforcement)
If the requirement is “deny access within 300 seconds,” the most deterministic way is to enforce it at the API/resource-server layer by:
using short access-token lifetimes (<= 300 seconds), and/or
adding token blacklisting / introspection-style checks in your APIs.
This avoids relying on refresh token expiration to enforce disablement.
About limiting refresh token lifetime per customer
A reconcile lambda can help with user provisioning and claims, but it won’t reliably solve the core issue of existing sessions and refresh tokens already issued. There isn’t a simple “per-customer refresh token TTL override” you can apply after the fact without an architectural approach like the ones above.
