If you believe that you have discovered a bug or issue with FusionAuth, please log an issue below.

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

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.

https://fusionauth.io/docs/extend/events-and-webhooks/events/user-registration-update

This is definitely an uncommon scenario, so there’s no out-of-the-box flow documented for it, but here’s one way to handle it:

Create a second Google IdP: FusionAuth supports only one native Google IdP, but you can set up an additional Google connection as a generic OpenID Connect (OIDC) IdP. This second IdP can request the elevated scopes you need for email access. See the OIDC docs here: OpenID Connect IdP in FusionAuth. Trigger reauthentication: When a user opts into the email client feature, redirect them through the second IdP’s OAuth flow to acquire the elevated scopes. This effectively escalates their session without forcing all users through additional authentication unnecessarily.

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.

FusionAuth doesn’t currently support setting a default IdP for an application or automatically forcing logins through an IdP. You’re welcome to submit a feature request on our GitHub issues page.

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.

Yes, FusionAuth offers a feature called Managed Domains that can help implement this type of flow. When you set up Managed Domains under an Identity Provider and enable it for your application, the hosted login page will initially display only an email input field. Based on the user’s email domain, FusionAuth will then either redirect them to the appropriate Identity Provider (such as for employee logins) or continue to the standard username/password login for other users.

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

Yes, you can disable the Facebook login and signup button through the FusionAuth dashboard. Navigate to Settings > Identity Providers, then edit the Facebook Identity Provider. At the top of the configuration page, you’ll find an “Enabled” toggle that lets you disable Facebook login globally for all applications. Alternatively, you can disable Facebook login for specific applications by using the application-level toggles at the bottom of the same page.

@impackt Great, glad you have a path forward.

@johnathon

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.

@md-tanveeraj Can you confirm how you are intergrating Google?

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

@eirikur That is awesome, thanks so much for sharing your settings.

You would have to add a hook in your IdP to make an API call to delete the user in FusionAuth. However, because the SoR will no longer have this user, the use will not be able to log in via FusionAuth either unless their password is reset.

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

We don’t currently support IdP initiated login.

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.

As far as I know it is not possible, I believe Google builds that text based upon the redirect_uri. I would assume you'd only see the fusionauth.io domain listed if you're using our hosted URL. If you are using an enterprise plan with a custom domain (login.example.com) you shouldn't see fusionauth.io mentioned.

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.