Single Sign-On (SSO)

Hunty supports Single Sign-On for corporate authentication, allowing a company's employees to log in to the platform using their existing identity provider instead of a separate Hunty username and password.

SSO is implemented via OpenID Connect (OIDC) federation. This works with any OIDC-compliant identity provider (IdP), including:

• Microsoft Entra ID (Azure AD)
• Okta
• Google Workspace
• Any other OIDC-compliant provider

SAML 2.0 is not a standard offering today. If a client's IdP only supports SAML, treat it as a case-by-case request rather than a standard "yes."

Each client company has its own isolated workspace in Hunty. If a company operates in multiple countries, each country has its own account inside that same workspace.

SSO is set up once per company, and automatically covers every country account under that workspace — no need to repeat the configuration per country. (A company that genuinely needs a different IdP per country can still get one — but this is the exception, not the default flow.)

Connecting SSO does not change who can access what inside Hunty:

• The first time a user logs in via SSO, Hunty automatically creates their account (just-in-time provisioning).
• That user has no roles or permissions until the assigned KAM grants them inside the platform.
• The client remains fully in control of who is provisioned: removing a user's access to the Hunty app/group in their IdP prevents new logins; existing sessions/roles are still managed by the KAM.

Before going live, get the list of expected users (and their intended roles) to the KAM so access is ready by the time the first employee logs in — otherwise users can authenticate but will see no permissions.

Once we receive these, we configure the connection on our side and return a Redirect URI that the client must register in their IdP's admin console (e.g., under "Redirect URIs" in an Azure AD app registration) to activate the flow.

Security note: Client Secrets are sensitive credentials — prefer a secure channel (e.g., a password manager share link) over plain email when possible.

1. Client asks about SSO and confirms which IdP they use.
2. Hunty requests the credentials listed above for that IdP.
3. Hunty configures the connection and generates the Redirect URI.
4. Client registers the Redirect URI in their IdP admin console.
5. Both sides test the login flow with a pilot user.
6. KAM assigns initial roles/permissions so users have access from their first login.
7. Go live.