Skip to content
InPolicy InPolicy Docs

Single sign-on (Google, Microsoft)

InPolicy supports Single Sign-On via two identity providers:

  • Google Workspace (OAuth 2.0)
  • Microsoft Entra (formerly Azure AD; OAuth 2.0)

Once SSO is connected, your team signs in with their existing work identity — no separate passwords. You can also pull users from the connected directory with a click instead of inviting them one-by-one.

What SSO does and doesn’t do

Section titled “What SSO does and doesn’t do”

SSO gives you:

  • Sign-in via the user’s Google or Microsoft account.
  • A directory you can browse and selectively import users from.
  • Automatic updates to name, email, and avatar when you re-run directory imports.
  • Domain-based filtering — only emails from your approved domains are accepted.

SSO does not automatically:

  • Provision every user in your directory. You still pick who to import.
  • Keep users synced in real time. Directory sync is manual in the current release — no scheduled sync.
  • Map directory groups to InPolicy roles. Role assignment is still per-user in InPolicy.

Connecting Google Workspace

Section titled “Connecting Google Workspace”

Prerequisites

Section titled “Prerequisites”
  • A Google Workspace Super Admin (or Delegated Admin with the right scopes).
  • Access to your Workspace’s OAuth consent screen.

Steps

Section titled “Steps”
  1. Users page → Add users → Import tab → Connect Google.
  2. You’re redirected to Google’s OAuth consent flow.
  3. Sign in with a Workspace admin account.
  4. Approve the scopes InPolicy requests:
    • openid email profile — basic identity.
    • https://www.googleapis.com/auth/admin.directory.user.readonly — to list users for the import UI. Read-only.
    • https://www.googleapis.com/auth/admin.directory.domain.readonly — to list your Workspace domains.
  5. Google sends you back to InPolicy. A new Directory connection row is created with a success banner.
  6. You’re shown the Select users step, where you can pick who to import. See Directory sync for the details.

The approved connection is stored in the backend with an OAuth refresh token. Tokens are long-lived but can expire if the admin who connected the directory is themselves removed from Workspace — in that case, reconnect.

Removing the Google connection

Section titled “Removing the Google connection”

From the Import tab, click the connected directory row → Disconnect. This deletes the stored refresh token on the backend. Users already imported remain in your tenant; only the sync capability is removed.

Connecting Microsoft Entra

Section titled “Connecting Microsoft Entra”

Prerequisites

Section titled “Prerequisites”
  • A Microsoft Entra Global Administrator (or a custom role with Directory.Read.All).
  • Access to approve admin-consent OAuth apps for your tenant.

Steps

Section titled “Steps”
  1. Users page → Add users → Import tab → Connect Microsoft.
  2. Redirected to Microsoft’s OAuth consent flow.
  3. Sign in with a Global Admin.
  4. Approve the scopes:
    • openid email profile — identity.
    • User.Read.All — list users.
    • Directory.Read.All — list directory metadata.
  5. Microsoft sends you back. The connection row is created.
  6. Proceed to the Select users step.

Removing the Microsoft connection

Section titled “Removing the Microsoft connection”

Same as Google — Import tab → Disconnect. Admins may also want to separately remove consent from the Entra side (Microsoft Entra admin center → Enterprise applications → InPolicy → Remove).

Signing in after SSO is connected

Section titled “Signing in after SSO is connected”

Once at least one provider is connected, the sign-in page at app.inpolicy.ai/signin shows Sign in with Google and/or Sign in with Microsoft buttons alongside the email/password form.

An end-user signing in via SSO:

  1. Clicks the Google or Microsoft button.
  2. Completes OAuth on their identity provider.
  3. Is redirected back to InPolicy.
  4. If their email matches an existing user record (e.g., imported from the directory), they’re signed in directly.
  5. If their email doesn’t match any user but matches an allowed domain, an implicit user record is created with the User role. Adjust their role on the Users page if needed.
  6. If the email doesn’t match an allowed domain, sign-in is rejected with “Domain not allowed.”

Domain allowlist

Section titled “Domain allowlist”

By default, connecting Google or Microsoft approves the primary domains associated with that Workspace/Entra tenant. If you want to restrict sign-in further (e.g., your Workspace has acme.com and acme.dev domains but you only want InPolicy for acme.com), adjust the allowlist from the SSO settings.

Users signing in from a domain not on the allowlist are rejected even if the OAuth succeeded at the provider level.

What happens when SSO breaks

Section titled “What happens when SSO breaks”

If the refresh token on the backend expires or the admin who connected the directory loses access:

  • Existing users can still sign in via SSO as long as Google/Microsoft hasn’t revoked their session — InPolicy doesn’t need the refresh token for end-user sign-in, only for directory imports.
  • Directory imports will fail until an admin reconnects.
  • Email/password sign-in continues to work independently.
Section titled “Related”