IPinfo supports Single Sign-On for Enterprise organizations. Members authenticate through the organization's own identity provider (SAML or OIDC) instead of IPinfo-managed credentials. The integration is built on WorkOS, which mediates the connection to the organization's identity provider.

SSO is configured entirely through the dashboard. It is not exposed as part of the public IPinfo API.

Availability

• Requires the Organization SSO entitlement, granted on Enterprise plans.
• Configuration actions (enable, connect identity provider) are restricted to the organization owner.
• One sign-in domain per organization.

Sign-in domain

• The domain is derived from the organization owner's own account email; it is not a free-text field.
• Whether a domain is eligible is validated by WorkOS, not IPinfo. Consumer mailbox domains (e.g. gmail.com) are rejected.
• A domain already claimed by another IPinfo organization cannot be claimed again.
• Once set, the sign-in domain cannot be changed or removed by the organization from the dashboard. Contact support@ipinfo.io for either.

Enabling SSO

From /dashboard/organization, the organization owner opens the SSO card and enables SSO. This creates a WorkOS organization scoped to the sign-in domain and advances to the identity provider connection step.

Possible outcomes:

Connecting an identity provider

Selecting Configure identity provider at /dashboard/organization/sso mints a single-use, SSO-scoped WorkOS Admin Portal link and redirects the organization owner there. This link:

• Is generated per click and is never persisted or logged.
• Is scoped with intent: sso, so it cannot be used to manage anything beyond the SSO connection.

Inside the Admin Portal, the owner (or their IT admin) selects an identity provider from a list that includes Okta, Microsoft Entra ID, Google Workspace SAML, and others, then completes that provider's connection using values WorkOS supplies (Assertion Consumer Service URL, SP Entity ID, or an IdP metadata URL, depending on the provider). Provider-specific walkthroughs are presented inside the Admin Portal itself; see WorkOS's integration guides for the current list. IPinfo does not store or process identity provider credentials directly.

How members are matched to IPinfo accounts

IPinfo identifies a member by the subject the identity provider asserts — the Okta user id, the Microsoft Entra object id, or the SAML NameID — not by their email address. The subject is recorded against the IPinfo account the first time that member signs in, and every later sign-in resolves the account from it.

This is what makes email changes safe. When a member is renamed at the identity provider, or the organization migrates to a new email domain, the next sign-in lands in the same IPinfo account — its API token, usage history, and membership are unaffected — and the address stored on the account is updated to the newly asserted one. Without the subject link, a changed address would look like a new person and create a second account.

Two consequences follow:

• Use a persistent NameID for SAML connections. A connection configured with NameID set to the email address ties the identity back to the very attribute that changes, so a renamed member is seen as somebody new. Providers offer a stable alternative — Okta's user.id, Entra's object id — and the persistent NameID format exists for exactly this. Contact support@ipinfo.io if a connection has already been used with an email-based NameID and members need re-matching.
• Membership is still what grants access. The subject decides which account signs in, never whether it may. A member removed from the organization is refused at sign-in immediately, even though their identity provider still authenticates them.

An email address the identity provider asserts that no IPinfo account holds yet is created as a new member account, verified, on first sign-in. If the address is already held by an account outside the organization, that account is refused — it joins through an explicit invitation instead.

Testing and connection status

The Admin Portal includes a Test sign-in step that verifies the SAML or OIDC handshake resolves correctly before the connection is relied on.

Once connected, every member of the organization (not only the owner) sees the sign-in domain and connection status at /dashboard/organization/sso.

Related

• WorkOS: Single Sign-On
• WorkOS: Admin Portal
• WorkOS: What is SAML and how does it work