app.us.honeyhive.ai) signs users in through Auth0. Enterprise customers connect their own identity provider (IdP) as an Auth0 enterprise connection attached to an Auth0 Organization for their company. Auth0 discovers the right Organization and IdP from the user’s email address, so your users never pick a connection by hand.
This page lists what HoneyHive needs from your IdP. HoneyHive creates and manages the Auth0 side for you. For self-hosted deployments, see Identity Provider instead.
To set up SSO, Contact us or reach out to your account team with the details listed in What to send HoneyHive.
How sign-in works
- HoneyHive starts a standard OpenID Connect authorization code flow with PKCE against HoneyHive’s Auth0 tenant, whose discovery document is published at
https://<auth0-domain>/.well-known/openid-configuration. - Auth0 asks for the user’s email address first (Identifier First Authentication).
- Auth0 matches the email domain against verified Organization domains (Organization Domain Discovery). If exactly one Organization matches, Auth0 selects it. If several Organizations share the domain, Auth0 shows an Organization picker. If none match, Auth0 shows an error.
- Within that Organization, Auth0 routes the user to the enterprise connection whose IdP domains include the email domain (Home Realm Discovery), and your IdP authenticates the user.
- Auth0 returns an ID token to HoneyHive. HoneyHive validates it, creates or updates the user, and adds the user to the HoneyHive organization whose email domains include the user’s domain.
Connection requirements
What to send HoneyHive
- SAML: your IdP metadata URL or XML (entity ID, single sign-on URL, and signing certificate).
- OIDC: your issuer URL, client ID, and client secret. The issuer must publish
/.well-known/openid-configuration. - The list of email domains your users sign in with.
- Your HoneyHive organization name, if it already exists.
Required user attributes
HoneyHive reads these claims from the ID token Auth0 issues after your IdP authenticates the user. Map your IdP attributes so Auth0 can populate them.
A sign-in fails if the ID token has no
sub, has neither email nor upn, or the address is not a valid email.
Unique identifier requirements
HoneyHive identifies a user account by email address, compared case-insensitively. Thesub claim is validated and stored, and is updated to the latest value on each sign-in.
- Use a stable, unique email per person. Two IdP users with the same email address sign in to the same HoneyHive account. Do not reuse addresses across people or send shared mailbox addresses.
- Email changes create a new account. If a user’s email changes (for example after a name change or domain migration), they sign in as a new HoneyHive user with no memberships. Contact us to migrate memberships.
NameIDformat does not affect account identity. HoneyHive matches accounts on email, so a transientNameIDdoes not split a user’s account. A persistent identifier (such as an employee ID or object ID) is still good practice in your IdP.- Send the same address users type at the prompt. Organization discovery runs on the email typed at the Auth0 prompt, but organization membership uses the
emailclaim in the token. Both must use a domain on your organization’s email domain list. - Sign in through SSO, not a password account. A HoneyHive username-and-password account (Auth0 subject
auth0|...) whose email matches your domain is not added to your organization automatically. Users should always sign in through the SSO prompt.
Group attributes
On multi-tenant SaaS, HoneyHive does not read IdP group claims. Access below the organization level is managed in HoneyHive:- Users who match your organization’s email domains join the organization as Org Member on first sign-in.
- Org Admins, Workspace Admins, and Project Admins add users to workspaces and projects and assign roles. See Inviting Teammates and Roles.
- To limit who can reach HoneyHive at all, restrict assignment of the HoneyHive application in your IdP.