One fewer password for a system full of candidate data.
Your recruiters already sign in to everything else through Microsoft Entra ID, Google Workspace or Okta. Point Hireall at the same provider and they sign in there too — with your conditional access, your device rules and your offboarding applying to the ATS like they apply to everything else.
Standards-based, self-service, no call with us.
Your admin sets it up in a panel and tests it before it is live.
OpenID Connect
Authorization Code flow with PKCE where your provider supports it. The ID token signature, issuer, audience and nonce are verified on every sign-in, and signing keys refresh themselves.
Only people you already invited
An address that is not already a user on your account is turned away. Nobody gets into your candidate database because they exist in your directory.
Domain allow list
Restrict sign-in to the e-mail domains you own, up to ten of them, for the case where your provider serves more than one organisation.
Your provider’s MFA counts — once
If your provider’s token states it already verified a second factor, Hireall accepts that and does not ask for another one. If it says nothing, our own second step still runs — single sign-on never quietly turns it off.
Tested before it is switched on
Hireall reads your provider's OpenID configuration when you save and refuses a setup it could not reach — so a typo in the issuer fails in the settings panel, not at nine on Monday.
The secret is encrypted at rest
Your client secret is stored encrypted in the database, the redirect URI is fixed to our own domain, and each sign-in attempt is single-use and expires in minutes.
An issuer, a client, a secret
Register Hireall as an application in your identity provider, paste the issuer URL, client ID and secret into the security settings, and add the domains you want to allow. Hireall discovers the endpoints and signing keys itself, so there are no certificates to upload and nothing to renew by hand. Only the account owner and super admins can see or change any of it.
Sign-in changes, permissions do not
Single sign-on decides how someone proves who they are. What they can see in Hireall is still decided by the role you gave them and the jobs they are assigned to. Roles are not read from your directory and cannot be set by a group claim, which means a change in your directory can never silently widen someone's access to candidate data.
The people who review the ATS before you buy it
IT, security reviewers and teams with a lot of seats.
One directory, one offboarding
Sign-in follows the conditional access and device policy you already run, instead of being a separate password nobody rotates.
- Your provider enforces your access rules
- Nothing to install, nothing to renew
- Set up without contacting us
The questionnaire before signature
Standards-based sign-in with verified tokens, an encrypted secret and a written answer on what is and is not supported.
- Token signature, issuer and audience verified
- Client secret encrypted at rest
- Second factor honoured, never quietly dropped
Twenty recruiters, four offices
One link gets the whole team in, and the domain allow list keeps it to the addresses you actually own.
- One sign-in link for the whole account
- Up to ten allowed e-mail domains
- Unknown addresses refused, not created
Supported, and not supported
Including the parts most vendors leave vague.
Not today — Hireall speaks OpenID Connect only. Every major identity provider supports OIDC, so this is rarely a blocker in practice, but if your organisation standardised on SAML, say so and we will tell you honestly where that sits rather than promising a date.
No. Users are invited in Hireall and given a role there; a person who exists in your directory but not in Hireall cannot sign in. That is a deliberate boundary — automatic provisioning into a system holding candidate data is the kind of convenience that creates access nobody reviewed.
Not at the moment. Single sign-on is an additional way in rather than a replacement, and password sign-in stays available. If mandatory SSO is a requirement for you, tell us — it is a product decision, not a technical obstacle.
No. Roles and per-job access are managed in Hireall. Group claims are not read, so nobody gains visibility over candidates because of a change made in your directory by someone who has never seen this ATS.
They can no longer authenticate through your provider, so the single sign-on route closes immediately. Because password sign-in remains available, offboarding is only complete when you also remove or archive the user in Hireall — and that is the step that revokes their access to candidate data.
It counts when your provider says so. If the sign-in token states that a second factor was already verified — Microsoft Entra ID and Okta both send this — Hireall accepts it, does not ask again, and writes the acceptance to the audit log. If the token says nothing, our own second step still runs rather than assuming; Google Workspace usually sends nothing here, so expect the extra step to stay for those sign-ins.
Sign in the way your company already does
Walk through the setup panel with us in a 30-minute demo.
Talk to our team
Tell us about your roles and team size — we'll map Hireall to your hiring process and the plan that fits.
Contact sales Priced per company, not per seat