Okta MCP Server Cursor IDE Setup (2026)

How do you set up the Okta MCP server in Cursor? Okta publishes an open source MCP server you run yourself — clone github.com/okta/okta-mcp-server, install it with the uv package manager, then point Cursor's mcp.json at it as a local command-based server with your Okta org URL and either device-code or JWT client-credentials authentication. Unlike most SaaS MCP integrations on this site, there's no hosted mcp.okta.com endpoint to point at directly — this is a self-hosted server, closer in shape to running your own local script than connecting to a vendor-managed URL.

Okta's server is worth the extra setup step because of what it touches: user accounts, group memberships, and app assignments in a real identity provider. Okta has built in an extra safety layer for exactly this reason — critical operations like deleting apps or deactivating users require explicit confirmation before executing, through MCP's elicitation capability, rather than running silently the moment a prompt requests them.

What You Can Do With Okta MCP in Cursor

Prerequisites

Step 1: Clone and Install the Server

git clone https://github.com/okta/okta-mcp-server.git
cd okta-mcp-server
uv sync

uv sync installs the Okta Python SDK and the server's other dependencies into a managed virtual environment — you don't need to separately pip install anything.

Step 2: Set Up Okta App Authentication

Before wiring up mcp.json, you need an Okta app integration that grants the specific OAuth 2.0 scopes the server needs to load its tools at startup (for example, okta.users.read, okta.groups.read, and write-scoped equivalents if you want the server to modify data, not just read it). Create this in your Okta admin console under Applications, following Okta's own app-setup guide for the MCP server — the exact scopes you grant should match only what you intend Cursor to be able to do.

Step 3: Add the Server to mcp.json

{
  "mcpServers": {
    "okta-mcp-server": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/okta-mcp-server", "okta-mcp-server"],
      "env": {
        "OKTA_ORG_URL": "https://your-org.okta.com",
        "OKTA_CLIENT_ID": "your-client-id",
        "OKTA_SCOPES": "okta.users.read okta.groups.read"
      }
    }
  }
}

Replace /path/to/okta-mcp-server with the actual local path from Step 1. OKTA_SCOPES is a space-separated list — match it to the scopes you actually granted the app integration in Step 2, not a broader set you might want later.

For JWT-based (client-credentials) authentication instead of the interactive device flow, add OKTA_PRIVATE_KEY (a PEM-formatted private key) and OKTA_KEY_ID to the env block. This route skips the browser step entirely, which matters for non-interactive or CI-style environments, but means the private key material lives in your local config — treat it with the same care as any other long-lived credential.

Step 4: Authorize and Verify

Restart Cursor. If you're using device-code auth (no OKTA_PRIVATE_KEY/OKTA_KEY_ID set), starting the server triggers a device authorization prompt: a user code appears, you open a browser, enter the code, and sign in with your Okta credentials to authorize. With JWT auth configured, this step is skipped — the server authenticates directly with the key.

In Cursor chat, try:

Look up the Okta user with email jane@example.com and show their group memberships

A response naming a real user and real groups confirms the connection. If nothing comes back, re-check OKTA_ORG_URL — a typo here (wrong subdomain, -admin suffix left in by mistake) is the most common first-setup failure, and it usually fails quietly rather than throwing an obvious error.

Practical Workflows

Access troubleshooting

Check whether the user finance-jsmith@example.com is assigned to the "Expense App" and is in the "Finance-Approvers" group

Onboarding audit

List every user created in Okta in the last 7 days who hasn't been assigned to any group yet

Pre-offboarding check

Before I deactivate this user, show me every app and group they're currently assigned to, so I know what access is being removed

Cross-reference with authorization code

Show me the exact claim names Okta sends in the ID token for group membership, so I can match them in the app's JWT validation logic

Troubleshooting

Server starts but every tool call fails with a scope error
OKTA_SCOPES in your mcp.json env block has to match what the Okta app integration was actually granted in Step 2. Adding a scope to the env variable without also granting it on the Okta app side does nothing — the app integration's granted scopes are the real limit.

Destructive action (deactivate user, delete app) seems to hang
This is the elicitation confirmation step working as designed — the server is waiting for explicit human confirmation before executing. Check your Cursor client for a pending confirmation prompt rather than assuming the server crashed.

Device-code prompt never appears
Confirm you haven't set OKTA_PRIVATE_KEY/OKTA_KEY_ID — if JWT credentials are present in env, the server uses client-credentials auth and skips the device flow entirely, which is expected, not a bug.

uv run fails immediately
Confirm uv sync completed successfully in Step 1 and that --directory in your mcp.json args points at the actual cloned repo path, not a relative path that resolves differently depending on Cursor's working directory.

Frequently Asked Questions

Q: Is there a hosted Okta MCP server, or do I have to self-host?
A: As of this writing, Okta's MCP server is distributed as open source for self-hosting via uv, not as a hosted mcp.okta.com-style endpoint. That's a real difference from most SaaS MCP servers covered on this site — budget for the clone-and-run step rather than expecting a one-line url config.

Q: Should I use device-code auth or JWT client-credentials?
A: Device-code auth is simpler for an individual developer testing locally — sign in once through the browser prompt. JWT client-credentials (via OKTA_PRIVATE_KEY/OKTA_KEY_ID) skips the interactive step, which matters for non-interactive environments, at the cost of managing a private key as a stored credential.

Q: Why do some actions require explicit confirmation before running?
A: Okta's server integrates MCP's elicitation capability specifically for destructive operations — deleting apps, deactivating users — to enforce human oversight before those actions execute. This is a deliberate safety feature given what the server has access to, not a limitation to work around.

Q: What scopes does a read-only setup need?
A: At minimum, scopes covering the resources you want to query — okta.users.read and okta.groups.read cover the common lookup workflows shown above. Grant write-scoped equivalents only if you actually want Cursor able to modify users or groups.

Q: Can I limit the server to a subset of my Okta org?
A: Access is governed by the scopes granted to the Okta app integration you create in Step 2, not by a separate MCP-level restriction — scope the app integration deliberately rather than granting broad admin-level scopes for convenience.

Related Guides

---