Choosing an authentication method

Compare the three ways the management agent can authenticate to Okta.

	API token	OAuth, private JWK	OAuth, X.509 certificate
Okta object needed	An API token	An API Services app	An API Services app
Where the credential lives	Encrypted in the MIM configuration	A JSON file on the MIM server	A Windows certificate store, TPM, or HSM
Private key can be non-exportable	No	No	Yes
Access is scoped	No, it inherits the token owner's permissions	Yes, by OAuth scope and admin role	Yes, by OAuth scope and admin role
MIM schema reflects granted access	No, the full schema is always shown	Yes	Yes
Setup effort	Lowest	Moderate	Moderate, plus certificate work

API token

This is the quickest option to set up. An API token carries the Okta permissions of the account that created it, and that account must stay active for the token to keep working.

Because a token carries no scope information the connector can read, MIM always displays the full user and group schema. MIM won't stop you from selecting an attribute or operation that the token's account isn't allowed to perform, so it's up to you to keep the MIM configuration in line with that account's access.

Choose this method when you want the simplest setup, or when you have an existing deployment that already uses it.

OAuth with a private JWK

This is the standard OAuth setup. The private key is a JWK in a file on the MIM server, and only its public half is registered in Okta. Okta can generate the key pair for you when you create the app, or you can bring your own.

Choose this method when you're comfortable with an access-controlled key file on the MIM server.

OAuth with an X.509 certificate

This uses the same OAuth flow, but the signing key comes from a Windows certificate instead of a file. This allows the private key to be held by a Windows cryptographic provider, TPM, or HSM, so it never needs to be exportable and never has to exist as a file.

Choose this method when your key-handling policy rules out storing a private key in a file.

Client secrets

There is no client secret option. Okta requires that a service app requesting Okta API scopes authenticates with private_key_jwt, and both OAuth options described here use it.

The OAuth service app

Both OAuth methods use an Okta API Services app. Setting one up involves:

1. Registering a public key in Okta

2. Granting the OAuth scopes for what MIM will manage

3. Assigning an admin role, and a resource set if you want to narrow it further

4. Entering the client ID and the key reference in MIM

The scopes determine what MIM presents in its schema, while the admin role determines what Okta actually permits at run time. These are separate controls, and both need to be configured correctly. See Creating the OAuth service app.