> For the complete documentation index, see [llms.txt](https://docs.lithnet.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lithnet.io/okta-ma/authentication/choosing-an-authentication-method.md).

# Choosing an authentication method

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

|                                    | [API token](/okta-ma/authentication/api-token.md) | [OAuth, private JWK](/okta-ma/authentication/oauth-with-a-private-jwk.md) | [OAuth, X.509 certificate](/okta-ma/authentication/oauth-with-an-x509-certificate.md) |
| ---------------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| 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](/okta-ma/authentication/creating-the-oauth-service-app.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.lithnet.io/okta-ma/authentication/choosing-an-authentication-method.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.