Connect your own identity provider (Okta, Entra ID, Google Workspace)

Connect your company's identity provider so your team signs in to InfraNest with the accounts you already manage in Okta, Microsoft Entra ID, Google Workspace or another OpenID Connect provider. This is for Enterprise plan admins who want access controlled centrally — someone removed at your provider loses access here too.

#Overview

• Your team signs in with accounts you already manage, instead of a separate InfraNest password.
• Someone removed at your provider can no longer sign in to InfraNest.
• Available on Enterprise plans. For signing in with Google, GitHub or Microsoft without your own provider, see Single sign-on and sign-in connections instead.

#Set it up

1. Go to Settings, then Sign-in, and choose Set up single sign-on.
2. Provider: pick Okta, Microsoft Entra ID, Google Workspace, or Another provider (OpenID Connect).
3. Email domain (recommended): enter the domain your people's addresses are on. Once verified, people can type their work address on the sign-in page and new people can join automatically. You can skip this — your team then uses your workspace's sign-in link, and new people join by invitation.
4. Create the app: copy the Redirect URL, then create an application for InfraNest at your provider using it as the redirect URL. Your provider gives you a Client ID and Client secret to paste back, plus one extra field depending on your provider:
   • Okta: your Okta domain, for example acme.okta.com.
   • Microsoft Entra ID: your tenant ID, or any domain that belongs to your tenant.
   • Google Workspace: nothing extra to fill in.
   • Another provider (OpenID Connect): the Discovery URL it publishes, usually ending in /.well-known/openid-configuration.
5. Try it: sign in at your provider with your own account, in a new tab. A connection can only be switched on once this test has passed.
6. Who gets in: choose what happens when somebody new signs in, and the role they get. Then choose Switch on.

InfraNest reads everything else — the sign-in address, the token address and your provider's signing keys — from the provider itself. If it cannot reach the provider, the connection is not saved, and the error explains what it tried.

Afterwards, each connection shows where it stands: connected to your provider, test sign-in passed, switched on, and whether an email domain is verified. It also shows your workspace's Sign-in link and keeps showing its Redirect URL, in case you need either again.

NoteThis setup flow is available on Enterprise plans.

#How your team signs in

1. Use your workspace's sign-in link, shown on the connection with a copy button. It looks like https://app.infranest.io/sso/acme, where acme is your workspace's sign-in name. People can bookmark it, and it works whether or not you have verified a domain.
2. Or choose Use single sign-on, the link under the Sign in button on the sign-in page. It asks for your workspace's sign-in name, or a work email address.
3. Or simply type a work email address on the sign-in page. If its domain is one you have verified, a Continue with … button appears.

You can also put the sign-in link in your provider's dashboard, so people can start from the InfraNest tile there.

TipYour workspace's sign-in name is its slug, found under Settings → General. Changing it changes the sign-in link, so a link someone bookmarked stops working.

When single sign-on is required, typing a work address on your domain shows Continue with … as the main button, with the password field folded away 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, depending on what you chose under "Decide who gets in" below.
2. Without a verified domain, people join by invitation instead. Invite them from Team as usual.
3. The invitation email opens a page with Continue with … your provider: they sign in there as the invited address, and they are in. If they already have an InfraNest account with that address, it is used, not duplicated.

Somebody who signs in through your provider with no invitation, no verified domain and no account linked to it is turned away, and no account is created for them.

People who already have an account, for example because they joined with a password, can link it to your provider under My account → Sign-in & security → Connected accounts. After that they sign in through your provider, domain or not.

InfraNest also recognises an existing account on its own, if its address is on your verified domain and your provider says the address is verified. Providers do not always say so: in Okta, a person an administrator created with a password has an unverified address until they confirm it. The test sign-in tells you when your provider did not confirm the address. Those people link from their profile instead, or confirm their address at your provider.

#Decide who gets in

Two separate settings live on the connection:

• Allowed email domains narrows which addresses may use it. Subdomains are not included — acme.com does not allow mail.acme.com.
• When somebody new signs in decides what a successful sign-in grants:
  • Do nothing — they still need an invitation.
  • Ask an admin — their sign-in raises a join request for an administrator to approve.
  • Add them straight away — they get a seat immediately, on the role you choose.

The third option exists only for your own identity provider, not for Google or GitHub sign-in, because only your provider knows who is allowed to use InfraNest: someone your IT has not assigned to the app in Okta or Entra ID cannot get past the sign-in screen at all. Google, by contrast, will happily authenticate every address at your domain — including contractors, shared mailboxes and people who left but whose account still exists.

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 had their own InfraNest workspace keeps it and gains a membership in yours.

#Give people roles from your own groups

If your provider already separates who does what — an infra-admins group and an infra-readonly one, say — InfraNest can use that instead of you setting a role per person here.

Under Credentials and claim names:

1. 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 are not used at all. After a test sign-in, InfraNest shows which field your provider actually used, with a button to use it.
2. Add a row per group: the group's name exactly as your provider writes it, and the role it should get here. Group names your provider has sent in earlier sign-ins are suggested as you type.

What to expect afterwards:

• Roles follow your provider. Move somebody to another group and their role here changes the next time they sign in.
• Your own changes stick. Change somebody's role here by hand and it stays as you set it — their groups stop deciding it from then on.
• A group you have not mapped changes nothing. Somebody whose groups match no row keeps the role they have, so a mistyped claim name cannot demote your whole team.
• Roles that can change or delete things cannot be mapped, the same as the default role. Raise individual people yourself.

#Confirming sensitive actions

Your workspace can ask people to confirm deletions, rebuilds and power actions by proving who they are again (Settings → Access policy). Someone who signs in through your identity provider can do that there: the confirmation shows Confirm with your provider, a small window opens, and they sign in again.

InfraNest only accepts it when your provider really asked them to sign in again, not when it let them through on a session it already had. It checks the sign-in time your provider sends, and a confirmation is used once, for the action it was asked for.

• Okta works as it is.
• Entra ID needs the auth_time claim added to the app, which takes a minute.
• Google Workspace cannot do this, because Google offers no way to make someone sign in again. People confirm with a passkey, an authenticator app or their password instead.
• Other providers work when they send auth_time in the ID token. If yours does not, the window says so.

If a browser blocks the window, allow pop-ups for InfraNest and try again.

#Rotate the client secret

1. Go to Credentials and claim names on the connection.
2. Enter the new secret.
3. Choose Replace.

WarningThe stored secret is never shown again, so leaving the field empty always keeps the current one — double-check you've pasted the new secret correctly before replacing it.

#Troubleshooting

• Test the connection first — it names the problem in most cases, such as an unreachable provider, or a provider now announcing a different issuer than the one this 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 workspace that requires its own provider. Signing in through the right one works.
• A provider that moved to a different tenant needs a new connection: the issuer is fixed when the connection is created, and every sign-in is checked against it. That is deliberate — it is what stops a provider being quietly swapped for another one.
• Your administrators can see every failed attempt, with the reason, in Settings → Audit Log.

#Claim names

Leave Claim names empty unless your provider uses non-standard names for a person's email or name. The defaults are correct for Okta, Entra ID and Google Workspace.