Configure XFA as the Identity Provider for Google Workspace Beta

Unlike the other identity-provider guides, XFA is the identity provider here: Google hands sign-in to XFA, which signs users in with a passkey and checks their device.

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.

Google tells XFA who is signing in by adding the user's email to the redirect as the login_hint parameter. Google only does this when Autofill email is turned on in the SSO profile (below), which is off by default.

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 or in your organization's email domains; anything outside is rejected. With no domains here or in the organization's email domains, no one can sign in (fail-closed), so set this 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 URL from 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 URI from XFA.
Use HTTP-POST binding.
Autofill email: turn it on and choose the login_hint format. Without it, Google doesn't send the user's email, and XFA can't sign anyone in.

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.

Super administrators keep their own sign-in

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.

Apps that already have an XFA connection

You may already protect apps that sign in with Google by putting an XFA connection (SAML or OAuth) between the app and Google. Once this integration exists, a sign-in to such an app can run the XFA check twice: once when Google hands the sign-in to XFA, and again in the app's own connection.

The XFA Dashboard marks these connections for you. It recognizes them by their Google sign-in URLs (accounts.google.com, oauth2.googleapis.com):

On the Enforcement page, their cards show Sign-ins through Google can be checked twice.
On the Google Workspace integration, a notice lists them, with a link to each.

Keeping both works. The connection still checks the device every time the app sends a user to sign in, also when Google reuses an existing session and doesn't hand the sign-in to XFA. It also lets you apply a different policy to that app. And the SSO profile in Google only applies to the organizational units or groups you assign it to, so users outside them are only checked by the connection.

To check only once, choose one of these:

Let Google Workspace cover the app: set up the app's single sign-on with Google directly, then delete its XFA connection. Users are then checked when they sign in to Google.
Keep the connection for those users: leave them out of the organizational units or groups the SSO profile is assigned to.

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 People page (under Identity), 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. The link is single-use and valid for 7 days.

To add a few users, click New user. To add many at once, import them from Google (next section).

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.

Import users from Google

Import the user list from the Google Admin console to provision many users in one go, with the recovery email Google already holds for each of them. You need the Administrator role in XFA, and your organization needs an identity provider connection.

In the Google Admin console, go to Directory > Users.
Click Download users, choose All user info columns and Comma-separated values (.csv), and download the file.
In the XFA Dashboard, open Identity > People and click Import from Google.
Choose the downloaded file. The file is read in your browser: only the users you select are sent to XFA.
Pick who to import. By default the list shows Active users from every Org unit. Filter on the organizational unit you assigned the SSO profile to, and on Status or Department if you need to.
Check the Secondary email column. It uses the user's Recovery email from Google. For a user without one, choose their Home secondary email, Work secondary email or Their own Google inbox, per user or for all of them at once. XFA never picks one for you.
Check the What happens column for each user, then click Import.
Optionally, send onboarding links straight away. New users are checked; users who already enrolled can't get a link.

The What happens column shows, for each user:

New user or Already in XFA. If an existing user's secondary email differs from the file, it shows the change as old → new: importing replaces it.
Already enrolled or Link sent with the date, so you don't send a second link by mistake.
Shared secondary email when several selected users get their link at the same address. Whoever reads that inbox can onboard all of them.
Advanced Protection for users in Google's Advanced Protection Program, who may not be able to sign in through a third-party SSO profile. Check them before rollout.

Users whose domain is neither one of your organization's email domains nor in any connection's Allowed email domains, and users listed twice in the file, can't be selected.

The import shows how many seats your selection uses. Imported users count as users of your plan; if the import would go past your seat limit, deselect some new users or add seats first.

Sending the link to the user's own Google inbox

Choose Their own Google inbox only for users who will onboard before the SSO profile applies to them: once it does, they can't open that inbox without XFA. They also have no separate recovery inbox until you set a secondary email. The People page keeps a warning on these users.

Send onboarding links

To send links later, select the users on the People page and click Send onboarding link. XFA queues the emails and sends them over the next few minutes; the People page then shows Link sent with the date.

XFA skips, and tells you why:

users who already enrolled,
users without a secondary email,
users who got a link less than 7 days ago. Click Resend anyway to send a new one; it replaces the earlier link.

Each user's onboarding state shows on the People page: Provisioned, Link sent, Enrolled, or Enrollment unknown when XFA couldn't check.

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.

What about a second factor?

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.