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:

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:

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:

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.

You should start by checking the relevant google documentation.

As of writing, this is what their doc says:

Using the email, email_verified and hd fields, you can determine if Google hosts and is authoritative for an email address. In the cases where Google is authoritative, the user is known to be the legitimate account owner, and you may skip password or other challenge methods.

Cases where Google is authoritative:

email has a @gmail.com suffix, this is a Gmail account. email_verified is true and hd is set, this is a Google Workspace account.

Users may register for Google Accounts without using Gmail or Google Workspace. When email does not contain a @gmail.com suffix and hd is absent, Google is not authoritative and password or other challenge methods are recommended to verify the user. email_verified can also be true as Google initially verified the user when the Google account was created, however ownership of the third party email account may have since changed.

So in this case, you want to check that hd is set as well as that email_verified is true.

With FusionAuth, you can check this using a reconcile lambda and looking at the id_token:

https://fusionauth.io/docs/extend/code/lambdas/google-reconcile https://fusionauth.io/docs/extend/code/lambdas/openid-connect-response-reconcile

Thank you from bringing this to light.

Identity Provider Hints
Managed Domains

To note, you will likely want to be listening to the registration.update webhook for changes to the registration object prompted by additional fields the user needs to have completed based on what is a required field for self service registration.

In the case of a user entering all these fields "manually" (as part of a registration form) we will create the user and the registration at the same time (thus transmitting all information, including all required registration fields, as part of the user.create and registration.create events).

However, in the case of a social login, the user and registration will be created after the IdP provider returns information via the user.create and registration.create events. Additional registration will be asked of the user as part of the complete registration process (if there are additional required fields) and that additional information will be transmitted as part of the registration.update event.

This approach allows you to avoid reauthentication for users who don’t need the extra scopes while supporting a higher-privilege flow for users who do.

If all your users share the same email domain, you could try Managed Domains to route them to the correct IdP.

Another option is to place a proxy in front of FusionAuth. The proxy could inspect incoming requests and append the idp_hint before forwarding traffic to FusionAuth. You can learn more about using a proxy setup here.

You can read more about Managed Domains here:
Managed Domains Documentation

One approach would be to append the parameter idp_hint to the login URL to redirect a user to the appropriate IdP login page. Please read the hints section in our documentation for more information.

Another way to disable the password and email login for a user would be to set their password to a random 25-character string. This would make the password essentially impossible to brute force and thus impossible for them to log in via the hosted login page.

The two most common implementations of Google + FusionAuth are via the hosted pages (where you have FusionAuth display a login with google - https://fusionauth.io/docs/v1/tech/identity-providers/google) or via writing your own login page and Google integration (login with google via API - https://fusionauth.io/docs/v1/tech/apis/identity-providers/google#complete-the-google-login)

I might need some more context to be able to provide additional assistance.

Thanks,
Josh

We have discussed adding support for SCIM which may provide some of these types of features assuming other IdPs also support this standard. This is on the roadmap: https://github.com/FusionAuth/fusionauth-issues/issues/106

This has come up a few times, we’ll likely end up adding it, but for now it is not possible. We have an open feature for this in GitHub.

Please feel free to upvote it or otherwise communicate your desire for this work to be done.

I know in the Google cloud console where you configure your credentials there is a customization option for the consent screen, but I do not know if that will modify this account chooser or not.