Okta

The Okta Workforce Identity connector reads users, groups, group memberships and sign-in activity from your Okta org, so Mesh can correlate those identities with accounts from every other connected system.

Okta Workforce Identity is the name to look for when you add the connector. Mesh also lists other, earlier Okta connectors — see which entry to pick.

It is read-only. Every request it makes is a read request; it never creates, changes or deletes anything in your Okta org.

What it reads

From Okta	Becomes in Mesh
Users and their profiles	User accounts
Enrolled MFA authenticators	Credentials
Groups and their members	Groups and membership
Applications, and their policies, services and resources	Application records
Organization, department and division on user profiles	Organization context
Sign-in and change events from the system log	Sign-in activity

The connector reads seventeen endpoints in total, grouped into Directory, Applications and Security. You choose which of them to read when you add the connector — see Step 3 for the full list.

How you grant that depends on the authentication method you choose:

• An OAuth service app needs these four scopes and nothing more: okta.users.read, okta.groups.read, okta.apps.read, and okta.logs.read.
• An API token has no scopes at all. It inherits the permissions of the account that created it, so that account needs the Read-only Administrator role.

For the full field-level detail — every endpoint, every mapped attribute — see the Okta connector reference.

Setup

Setting Okta up has two halves. Do them in order.

Step	What you do	Where
1. Set up Okta	Create the credential and grant the four read permissions	Okta Admin Console
2. Set up in Mesh	Add the connector with the five-step wizard and verify the first collection	Axiad Mesh

You need the credential from the first half before you can finish the second, so start in Okta.

Choosing an authentication method

Okta offers two ways to authorize a read-only integration: an OAuth service app, which is limited to exactly the four permissions above, and an API token, which is limited by the admin role of the account that created it. Axiad recommends the service app. The first half of the guide covers both.

Mesh names them after the protocol they use — the service app is Private Key JWT, and the API token is Bearer. The setup wizard collects an API token today.

A trap worth knowing about before you start

Okta controls access two ways, and only one of them fails loudly.

• The wrong permission makes Okta refuse the request outright. You will see the error.
• The wrong admin role makes Okta answer normally, but with fewer records than exist. Nothing looks wrong.

That second case is the most common cause of an Okta connector that appears healthy while under-reporting. Both setup pages call out where it bites.