Configure XFA as the Identity Provider for Google Workspace Beta
This integration is different from the other identity-provider integrations. With Okta, Microsoft Entra ID, OneLogin and PingIdentity, your existing identity provider still authenticates the user and XFA is added as an extra factor that verifies the device.
For Google Workspace, XFA becomes the identity provider. Google delegates sign-in to XFA, and XFA authenticates the user passwordlessly with a passkey (Built-in passkey) before asserting their identity back to Google. There is no password step: the passkey on a trusted device is the sign-in, and XFA still enforces device security as part of it.
Passwordless Google Workspace sign-in is in beta and is enabled per organization. If you don't see the Identity Provider integration in your dashboard, contact XFA to have it turned on. Exact field labels in the XFA Dashboard and the Google Admin console may differ slightly from the other guides; the steps below describe the configuration you need to end up with.
Note: This guide assumes that you have an account set up with XFA for your organization and that you're an admin for that organization on both XFA and a super administrator in the Google Admin console. If you do not have an account, you can create one at https://dashboard.xfa.tech/signup.
How it works
When a user opens a Google Workspace application, Google redirects them to XFA to sign in. XFA authenticates the user with a passkey on a device they've enrolled with XFA (Built-in passkey), checks the device's security posture, and returns a signed SAML assertion to Google. Google trusts that assertion and lets the user in.
Because XFA owns the sign-in, the user never types a Google password. Their first device is bootstrapped through an admin-provisioned recovery step (below). Afterwards, sign-in is a single passkey tap on a trusted device.
Create an Identity Provider integration in XFA Dashboard
After logging in to the XFA Dashboard, navigate to the Enforcement page, click on New and select Identity Provider as the integration type.
You'll receive the information Google needs to trust XFA:
Single Sign-On URL: the XFA sign-in page URL.Issuer URI(Entity ID): identifies XFA to Google.- a certificate you can download by clicking on Download Certificate, which Google uses to verify XFA's assertions.
Keep this information handy for the Google configuration in the next step.
On the same integration you'll also configure:
- Allowed email domains: the domain(s) of your Google Workspace (for example
example.com). XFA only ever authenticates and asserts emails in these domains; anything outside is rejected. Leaving this empty rejects everyone (fail-closed), so set it before going live. - Service Provider details: the Entity ID and Assertion Consumer Service (ACS) URL that Google gives you (see the next step). You can leave these blank for now and fill them in after configuring Google.
Leave the tab open; you'll return to it once Google gives you its Entity ID and ACS URL.
Configure single sign-on in Google Workspace
In the Google Admin console, go to Security > Authentication > SSO with third-party IdP and set up a third-party identity provider profile:
- Sign-in page URL: the
Single Sign-On URLfrom XFA. - Sign-out page URL: your organization's sign-out or dashboard URL.
- Verification certificate: upload the certificate you downloaded from XFA.
- IdP entity ID: the
Issuer URIfrom XFA. - Use HTTP-POST binding.
Save the profile, then assign it to the organizational units or groups whose users should sign in through XFA. Start with a small pilot organizational unit before rolling it out organization-wide.
Google will show you the Entity ID and ACS URL for its side of the trust. Copy them.
Google excludes super administrators from third-party SSO profiles automatically. They continue to sign in with their Google password, even in an organizational unit you assign to XFA, so you always have a way back into the Admin console if the XFA configuration needs fixing. You don't need to carve out a separate break-glass organizational unit for that.
Everyone else in an assigned organizational unit signs in through XFA.
Complete the integration in XFA Dashboard
Go back to the XFA Dashboard and fill in the remaining Service Provider details for the integration:
- Service Provider Entity ID: the Entity ID from Google.
- Assertion Consumer Service URL: the ACS URL from Google.
Click Next to save the integration and adjust any device-security policies you want to apply during sign-in.
Provision users for their first device
Because XFA now owns sign-in, a brand-new device has no passkey yet, and the user usually can't receive mail in the very Google inbox they're signing in to. So the first device is bootstrapped by an admin.
On the Users page, provision each user who will sign in through XFA with a secondary email: a personal or alternate address they can reach. You can then send them an onboarding link at that address, which lets them register their passkey without ever typing a password.
If you'd rather not email a link, you can instead generate a one-time onboarding password for a user and hand it to them over a channel of your choosing.
How users sign in
- First device: the user opens the onboarding link from their secondary email (or enters the onboarding password you gave them) and registers a passkey on their device. XFA checks the device's security as part of it, and that passkey is their sign-in to Google from then on.
- Every device after: the user taps their passkey, with no password and nothing to type, and XFA confirms the new device on a device they've already enrolled before signing them in.
XFA replaces Google's password sign-in entirely, so there's no separate second factor to lose: the passkey on a device you've explicitly trusted with XFA is the strong factor. This is XFA's Built-in passkey. Read more in the Built-in passkey documentation.
If you still want one, nothing stops you: turn on Google's own 2-Step Verification for these users in the Google Admin console, the regular way. Google then asks for it on top of the XFA passkey.