Halo's native Okta integration connects your identity platform to your service desk — giving your team SSO into Halo, enforcing MFA automatically, and keeping your users and technicians in sync without any manual admin.
✓ SSO for agents & end users✓ MFA enforcement✓ Automated user provisioning✓ Self-service portal auth✓ Continuous user sync✓ Native — included in every licence
What you get
Four ways Okta connects your identity to Halo.
Okta is designed to be the identity layer across your entire technology stack. Halo's native integration plugs straight in — so the same identity controls that protect your other tools protect your service desk too.
Single Sign-On
Sign in to Halo with your Okta identity
Agents and end users authenticate to Halo using their existing Okta credentials — the same login they use for every other tool in your stack. No separate Halo password, no additional account to manage. SSO can be applied to agent logins, the self-service portal, or both independently.
✓Agents sign in to Halo using their Okta account
✓End users access the self-service portal via Okta SSO
✓One identity for every tool in your stack — including Halo
Multi-Factor Authentication
Your Okta MFA policy applies to Halo automatically
If you enforce MFA through Okta's adaptive policies, those controls extend to Halo at no extra configuration cost. When a user authenticates to Halo via Okta SSO, they pass through the same MFA challenge as any other connected application — no separate MFA setup needed inside Halo.
✓Existing Okta MFA and adaptive policies cover Halo
✓No separate MFA configuration required in Halo
✓Consistent security posture across your entire application estate
Automated Provisioning
Users and technicians stay in sync automatically
Halo continuously syncs users and technicians from your Okta directory using the Halo Integrator. Okta groups map directly to Halo roles — new starters appear in Halo when they're added to the right Okta group. Leavers lose access when their account is deactivated. No manual user management, no stale records, no access drift.
✓Continuous sync via Halo Integrator — runs automatically
✓New starters provisioned in Halo without manual admin
✓Leavers de-provisioned when their Okta account is deactivated
Self-Service Portal
End users access the portal with zero friction
The Halo self-service portal can be configured to authenticate via Okta — so end users open the portal and they're already signed in. No forgotten passwords, no separate portal account, no tickets raised about access. Okta handles authentication; Halo handles the request.
✓Portal authenticates via Okta SSO — no second login
✓User credentials protected to meet governance requirements
✓Works alongside any tech stack — Okta is platform-agnostic
The detail
Everything the integration delivers.
The full feature set — active from day one, included in your Halo licence, no middleware, no extra subscriptions.
Agent SSO login
Agents sign in to Halo using their Okta identity. No separate Halo password — Okta handles authentication end-to-end.
End user SSO login
End users access the Halo self-service portal using the same Okta credentials they use across every other application. Frictionless from the first visit.
MFA enforcement
Halo inherits MFA from your existing Okta adaptive policies — no separate MFA setup needed inside Halo itself.
Automated user sync
End users in Okta are continuously synced into Halo via the Halo Integrator. Your Halo user list always reflects your actual Okta directory.
Automated technician sync
Technicians are provisioned and updated in Halo from your Okta directory. Okta group membership controls Halo roles — changes in Okta flow through automatically.
Automatic de-provisioning
When a user's Okta account is deactivated, their Halo access is removed in the next sync cycle — no manual offboarding required.
Self-service portal auth
The Halo self-service portal can use Okta for authentication — end users land in the portal already signed in, no extra credentials needed.
Group-based role assignment
Okta groups map directly to Halo roles and sites. Provisioning follows your existing group structure — no manual role assignment in Halo.
Credential & governance compliance
User credentials are managed by Okta, meeting organisational requirements for privacy, security governance, and audit compliance.
Platform-agnostic identity
Okta works across Microsoft, Google, AWS, and hundreds of other apps. The Halo integration fits naturally into a multi-cloud or mixed-vendor environment.
First-party integration
The Okta integration is built and maintained by Halo's own engineering team. No third-party middleware, no custom connector to manage.
No extra cost — ever
The full Okta integration — SSO, MFA, user provisioning, portal auth — is included in every standard Halo licence. No add-ons required.
Getting connected
How the integration is configured
Setup is handled from within Halo and your Okta admin console. No middleware, no third-party connectors, no software to install.
1
Connect Okta in Halo
In Halo, go to Configuration → Integrations → Identity Management and open the Okta module. Enter your Okta instance URL (no trailing parameters). From Halo v2.232.1+, choose your authentication method — Basic Auth (API token) or OAuth2. The integration ships with every Halo licence — nothing to install.
2
Create an API token in Okta
In Okta, go to Security → API and click "Create token". Name the token, set any IP limitations, and save it. Paste the token into the API Token field in the Halo Okta integration, then click "Test Credentials" to confirm the connection is working. (OAuth2 users follow the separate OAuth guide in Halo instead.)
3
Create an OIDC application in Okta
In Okta, go to Applications → Applications and create a new App Integration. Choose Web as the application type and OpenID Connect as the sign-in method. Enable Authorization Code and "Allow ID Token with implicit grant type". Then add the redirect URIs: for agents use https://YOURHALODOMAIN/auth/account/openidresponse and for portal users use https://YOURHALOPORTALDOMAIN/auth/account/openidresponse.
4
Configure field mappings and group assignments
In the Halo Okta module, configure the Field Mappings tab to map Okta user and agent attributes to Halo fields. Use the Site/Agent Mappings tab to map Okta groups to Halo sites and roles, and the Advanced tab for agent role and board assignments. This is how Okta group membership controls access and role within Halo.
5
Run the initial import and enable automatic sync
In the Imports tab, set your matching fields and the Okta statuses to treat as active. Run a manual import to bring users and agents into Halo for the first time, then enable the Halo Integrator to keep the sync running automatically going forward.
6
Enable Okta SSO in the Single Sign-On tab
In the Single Sign-On tab of the Okta module, enable SSO and enter the Client ID from your Okta application. Choose whether SSO applies to agents, end users, or both. Optionally enable automatic redirect — Halo recommends testing SSO login first before turning this on. Once enabled, the Okta login button appears on the Halo login screen.
Before you start
What you'll need to do in your Okta tenant
The Okta integration requires some activity inside your own Okta admin console before Halo can connect. These steps need an Okta administrator — they can't be completed by Allied ESM on your behalf.
Okta admin
Okta role with the right API scopes
Halo recommends using the Super Admin role in Okta for the integration. If you prefer a custom role, it must have at minimum: okta.users.read, okta.groups.read, and okta.apps.read scopes. Without these, the user sync and group mapping will not work.
Okta admin
Create an API token in Okta
An Okta administrator must generate an API token under Security → API. This token is pasted into Halo to authenticate the connection. Tokens are tied to the generating user's permissions — if that user is deactivated, the token stops working.
Okta admin
Create a Web/OIDC application integration
An Okta administrator must create a Web application using OpenID Connect in the Okta admin console, with Authorization Code grants enabled and the correct redirect URIs for your Halo agent and portal domains. This application provides the Client ID used by Halo's SSO configuration.
Okta admin
Plan your Okta group structure before mapping
Okta groups drive both user provisioning and role assignment in Halo. Your Okta admin should agree the group structure before configuring mappings — which groups correspond to Halo agents, which to end users, and how roles within Halo should be assigned from group membership.
Ongoing
Keep the Halo Integrator running and tokens current
The Halo Integrator handles the automatic sync between Okta and Halo. If it stops, new starters won't be created and leavers won't be de-provisioned. API tokens must also be rotated in line with your security policy — if the token expires or the generating user is deactivated, the sync breaks.
Real-world uses
Three ways this changes the day-to-day.
These are the most common ways organisations put the Okta integration to work from go-live.
01
A new starter is ready in Halo before their first day
HR adds the new starter to Okta as part of the standard onboarding process. Within the hour, the Halo sync picks them up — their user record is created, they're assigned to the right department, and they can sign in to the self-service portal on day one using their Okta credentials. No manual user creation, no IT ticket about portal access.
Added to Okta→Synced to Halo→Ready on day one
02
An agent logs in to Halo for the first time — no setup needed
A new service desk agent joins the team. They navigate to the Halo login page, click "Sign in with Okta," pass their MFA challenge, and they're in — landing directly in their queue. IT never created a Halo account or set a password. The Okta sync had already handled it.
Click Sign in with Okta→MFA fires→In Halo
03
A leaver loses Halo access the moment their account is deactivated
An employee leaves the business. IT deactivates their Okta account. At the next sync, Halo removes their access automatically — no lingering active accounts, no need to disable users in a second system, no audit findings about orphaned access. Okta is the single source of truth; Halo follows it.
Okta deactivated→Sync runs→Halo access removed
Common questions
Frequently asked questions
Is the Okta integration included in every Halo licence?
Yes. The full Okta integration — SSO, MFA enforcement, automated user provisioning, and self-service portal authentication — is a native, first-party Halo feature included in the standard monthly licence. There is no middleware, no third-party connector, and no add-on subscription required.
Does Okta SSO work for both agents and end users?
Yes. SSO via Okta can be configured independently for agent (technician) logins and end user access to the self-service portal. You can enable agent SSO first and extend it to end users later, or enable both at the same time — whatever suits your rollout plan.
Can I enforce MFA for Halo using my existing Okta policies?
Yes. When users authenticate to Halo via Okta SSO, your existing Okta sign-on and adaptive MFA policies apply automatically. If your policy requires MFA for all app sign-ins, that challenge fires when users log in to Halo — no additional MFA configuration is needed inside Halo itself.
How does automated user provisioning work?
Halo's Okta integration uses the Halo Integrator to run automatic syncs between your Okta directory and Halo. Okta groups are mapped to Halo roles and sites — when a user is added to an Okta group, they're provisioned in Halo with the correct role automatically. You run an initial manual import to bring existing users across, then enable the Halo Integrator to keep the sync running. Leavers lose access when their Okta account is deactivated.
We don't use Microsoft — does Okta work as a standalone identity provider for Halo?
Yes. Okta is a platform-agnostic identity provider — it doesn't require Microsoft 365 or Azure. If your organisation uses Okta as its primary identity platform (whether on Google Workspace, AWS, or a mixed environment), Halo's Okta integration gives you SSO, MFA, and user provisioning without any dependency on Microsoft tools.
What's the difference between using Okta and Entra ID for Halo SSO?
Both integrations deliver the same outcome — SSO, MFA enforcement, and automated user provisioning into Halo. The difference is which identity platform you already run. If your organisation is Microsoft-native and uses Entra ID (formerly Azure AD), use the Entra ID integration. If you use Okta as your primary identity provider — especially in non-Microsoft or mixed-vendor environments — use the Okta integration. Halo supports both natively.
We're already live on Halo — can we add Okta SSO without disruption?
Yes. The Okta integration can be added to an existing live Halo environment. Allied ESM can scope and deliver the full setup — application configuration, sync setup, and SSO rollout — without disrupting your current workflows. We typically phase the rollout: configure and test with a small group first, then extend to the full user base once everything is verified. Contact us to discuss what's involved for your setup.
Does this work with HaloPSA as well as HaloITSM?
Yes. The Okta integration is available across both HaloITSM and HaloPSA. The full feature set — SSO, MFA, user provisioning, and portal authentication — works identically regardless of which Halo product you run.
Ready to connect Halo to your Okta identity?
Allied ESM can scope and configure the full Halo + Okta integration — whether you're starting a new Halo implementation or adding SSO to an existing environment. Talk to us to find out what's involved.