> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Google Workspace

> Let users sign in to Iru Identity with their Google Workspace accounts using the built-in connection template for federated authentication and provisioning.

Connecting **Google Workspace** lets your users sign in to Iru (and reach the
apps you have assigned them) using the Google accounts they already have. Iru
provides a **Google Workspace template** that pre-fills the standard
configuration, so this is one of the quickest providers to connect.

<Info>
  Most organizations that use Iru Identity as their identity provider have users
  sign in directly with a passkey or the Iru Access app. Connect Google Workspace
  when you use Iru Identity as an authentication layer into the Iru platform
  rather than your primary identity provider, or to ease a migration onto Iru
  Identity. See [Federated Authentication](/en/identity/connections/connections-overview).
</Info>

<Note>
  You need administrator access to your Iru tenant, and access to your Google
  Workspace administrator console, to complete this connection.
</Note>

## Before you begin

<Steps>
  <Step title="Confirm your sign-in domains">
    Note the email **domains** your users sign in with (for example,
    `yourcompany.com`). You can restrict the connection to these domains so only
    users in them use it.
  </Step>

  <Step title="Decide how Iru matches users">
    When someone signs in through Google, Iru matches them to a user in your
    directory. Decide which value to match on, typically the user's email or
    username. See [user matching](/en/identity/connections/connections-overview#what-you-configure-on-every-identity-provider-connection).
  </Step>

  <Step title="Make sure your users exist in Iru">
    Sign-in through a connection resolves to an existing Iru user. Add or import
    your users first; see [Importing users](/en/identity/directory/importing-users)
    or [Directory Sync](/en/identity/directory/directory-sync).
  </Step>
</Steps>

## Connect Google Workspace

<Steps>
  <Step title="Add the connection">
    In **Access → Authentication**, add an **authentication method** and choose the
    **Google Workspace** template. Using the template fills in the standard
    settings for you.
  </Step>

  <Step title="Authorize Iru with Google">
    Follow the prompts to authorize Iru against your Google Workspace
    organization, signing in with a Google **super administrator** account when
    asked and consenting to the standard sign-in scopes (`openid`, `email`, and
    `profile`). If your organization provides its own OAuth client, create it in
    the Google Cloud Console, add the redirect URI Iru shows for this connection,
    and copy its client ID and secret into Iru. Google's console screens can
    change; follow Google's current documentation if the prompts differ.
  </Step>

  <Step title="Choose what the connection is used for">
    Select the connection's **use cases**: **end-user sign-in**, **device
    enrollment**, or both. Most setups enable end-user sign-in.
  </Step>

  <Step title="Restrict to your domains">
    If you want only users in specific email domains to use this connection,
    enable **domain restrictions** and add those domains.
  </Step>

  <Step title="Set user matching">
    Choose how Iru matches a Google sign-in to an Iru user (by UPN, username,
    external ID, or a custom attribute). Pick a value that is unique and stable
    for every user.
  </Step>

  <Step title="Save the connection">
    Save, then sign in as a test user whose email is in an allowed domain to
    confirm the hand-off to Google works end to end.
  </Step>
</Steps>

<Tip>
  Test with a single user before rolling the connection out broadly. If sign-in
  fails to land on the right user, revisit your **user matching** choice; the
  matched value must be present and unique for everyone who uses the connection.
</Tip>

## How sign-in works once connected

When someone signs in, Iru hands the sign-in off to Google, Google confirms the
user, and Iru continues the session before evaluating the app's
[authentication policy](/en/identity/authentication/authentication-policies)
before granting access. For the full picture, see
[System architecture](/en/identity/getting-started/system-architecture).

## Related

<CardGroup cols={2}>
  <Card title="Federated Authentication" icon="plug" href="/en/identity/connections/connections-overview">
    Use cases, domain restrictions, and user matching, explained in one place.
  </Card>

  <Card title="Microsoft Entra ID" icon="microsoft" href="/en/identity/connections/microsoft-entra-id">
    Connect Microsoft Entra ID for sign-in with its own template.
  </Card>

  <Card title="Sign-in experience" icon="arrow-right-to-bracket" href="/en/identity/authentication/sign-in-experience">
    Shape what users see when they sign in.
  </Card>

  <Card title="Custom SAML" icon="shield-halved" href="/en/identity/connections/custom-saml">
    Connect a provider that is not covered by a template.
  </Card>
</CardGroup>