# Connect your own identity provider (Okta, Entra ID, Google Workspace) > If your company already manages accounts in Okta, Microsoft Entra ID, Google Workspace or another OpenID Connect provider, your team can sign in to InfraNest… Source: https://infranest.io/docs/connect-your-identity-provider Last updated: 2026-10-26 --- Connect your company's identity provider — Okta, Microsoft Entra ID, Google Workspace, or another OpenID Connect provider — so your team signs in with the accounts your IT already manages. This is for admins on Enterprise plans. ## Overview - Your team signs in with the accounts they already have at work. - You keep control in one place: someone removed at your provider can no longer sign in to InfraNest. - If you just want people to sign in with a personal Google, GitHub or Microsoft account (without your own provider), see Single sign-on and sign-in connections instead. ## Set it up 1. Go to **Settings → Sign-in** and choose **Set up single sign-on**. 2. Under **Provider**, pick Okta, Microsoft Entra ID, Google Workspace, or **Another provider (OpenID Connect)**. 3. Under **Email domain** *(Optional)*, enter the domain your team's addresses are on. Verifying it lets people type their work address on the sign-in page and lets new people join automatically. You can skip this — your team will use your organization's sign-in link instead, and new people join by invitation. 4. Under **Create the app**, copy the **Redirect URL** and use it to create an application for InfraNest at your provider. Paste back the **Client ID** and **Client secret** your provider gives you, plus the one extra field it needs: - **Okta**: your Okta domain, e.g. `acme.okta.com`. - **Microsoft Entra ID**: your tenant ID, or any domain in your tenant. - **Google Workspace**: nothing extra to fill in. - **Another provider (OpenID Connect)**: the **Discovery URL**, usually ending in `/.well-known/openid-configuration`. 5. At the **Try it** step, sign in at your provider with your own account in a new tab. You can only switch the connection on after this test passes. 6. At the **Who gets in** step, choose what happens when somebody new signs in, and the role they get. Then choose **Switch on**. > [!NOTE] InfraNest reads the sign-in address, token address and signing keys straight from your provider. If it can't reach your provider, the connection isn't saved, and the error explains what it tried. ![Connect your own identity provider (Okta, Entra ID, Google Workspace)](/media/d81c948b-2c1e-4053-b0c0-48c072fcea0c) Afterwards, each connection shows where it stands — connected, test sign-in passed, switched on, and whether an email domain is verified — along with your organization's **Sign-in link** and its **Redirect URL**. ## How your team signs in 1. Use your organization's **Sign-in link**, shown on the connection with a copy button (for example `https://app.infranest.io/sso/acme`). People can bookmark this; it works with or without a verified domain. 2. Or, from the sign-in page, choose **Use single sign-on** under the **Sign in** button, and enter your organization's sign-in name or a work email address. 3. Or, type a work email address directly on the sign-in page. If its domain is verified, a **Continue with …** button appears. You can also add the sign-in link to your provider's dashboard so people can start from the InfraNest tile there. > [!TIP] Your organization's sign-in name is its slug, found under **Settings → Organization**. Changing it changes the sign-in link, so any bookmarked link will stop working. When single sign-on is required, typing a work address shows **Continue with …** as the main button, with the password field tucked under **Sign in with a password instead**. ## How new people join 1. **With a verified email domain**, somebody new can join the moment they first sign in, following what you chose under Decide who gets in. 2. **Without one**, invite them from **Members** as usual. Their invitation email includes a **Continue with …** button for your provider — they sign in as the invited address and they're in. If they already have an InfraNest account with that address, it's reused, not duplicated. 3. Somebody who signs in through your provider with no invitation, no verified domain, and no linked account is turned away, and no account is created. 4. People who already have an InfraNest account (for example, created with a password) can link it under **My account → Sign-in & security → Connected accounts**. After that, they sign in through your provider, domain or not. ## Decide who gets in There are two separate settings on the connection: - **Allowed email domains** narrows which addresses may use it. Subdomains aren't included automatically — `acme.com` does not also allow `mail.acme.com`. - **When somebody new signs in** controls what a successful sign-in grants: 1. *Do nothing* — they still need an invitation. 2. *Ask an admin* — their sign-in raises a join request for an administrator to approve. 3. *Add them straight away* — they get a seat immediately, on the role you choose. The third option is only available for your own identity provider, not for Google or GitHub sign-in — only your provider knows who's actually allowed to use InfraNest. The role new members land on can never be owner, or any role that can change or delete things; raise individual people afterwards. Joining is always additive: somebody who already runs their own InfraNest organization keeps it and simply gains a membership in yours. ## Give people roles from your own groups If your provider already separates who does what into groups, InfraNest can use that instead of you setting a role per person. 1. Under **Credentials and claim names**, fill in **Groups claim** with the field your provider sends groups in (Okta usually sends `groups`; Entra ID sends `roles` for app roles). Leave it empty and groups aren't used at all. 2. After a test sign-in, InfraNest shows which field your provider actually used, with a button to use it. 3. Add a row per group: the group's name exactly as your provider writes it, and the role it should get here. Previously seen group names are suggested as you type. What to expect afterwards: - Roles follow your provider — move somebody to another group and their role changes next time they sign in. - Changing somebody's role here by hand sticks — their groups stop deciding it from then on. - A group you haven't mapped changes nothing — people keep their existing role. - Roles that can change or delete things can't be mapped here either; raise those people by hand. ## Confirming sensitive actions Your organization can require people to confirm deletions, rebuilds and power actions by proving who they are again, under **Settings → Access policy**. - Someone signed in through your provider sees **Confirm with** *your provider*; a small window opens and they sign in again. - InfraNest only accepts this when your provider genuinely asked for a fresh sign-in, checking the sign-in time it sends. Each confirmation is used once, for the action it was requested for. - **Okta** works as-is. - **Entra ID** needs the `auth_time` claim added to the app first. - **Google Workspace** can't do this — people confirm with a passkey, an authenticator app, or their password instead. - **Other providers** work if they send `auth_time` in the ID token; otherwise the window will say so. If a browser blocks the confirmation window, allow pop-ups for InfraNest and try again. ## Rotating the client secret 1. Go to **Credentials and claim names**. 2. Enter the new secret. 3. Choose **Replace**. > [!WARNING] The stored secret is never shown again. Leaving the field empty always keeps the current one in place. ## Claim names Leave **Claim names** empty unless your provider uses non-standard names for a person's email or name. The defaults already work for Okta, Entra ID and Google Workspace. ## Troubleshooting - **Run Check (test sign-in) first** — it names most problems directly, such as an unreachable provider or a provider now announcing a different issuer than the one the connection was set up with. - **"Your identity provider rejected this connection's credentials"** means the client secret expired or was rotated at your provider — replace it as described above. - **" does not use for single sign-on"** means the person belongs to another organization that requires its own provider — signing in through the right one works. - **A provider that moved to a different tenant** needs a brand-new connection, since the issuer is fixed when a connection is created and checked on every sign-in. - Administrators can see every failed attempt, with the reason, in **Settings → Audit Log**.