# Okta MCP > Okta MCP Server connects your AI agent directly to Okta Identity Cloud's core services. It manages user lifecycles, handles access control, and provides real-time security visibility for IT operations. Instead of clicking through admin dashboards, you talk to the server to create users, reset credentials, or terminate sessions instantly. ## Overview - **Category:** industry-titans - **Price:** Free - **Tags:** authentication, user-provisioning, sso, identity-management, access-control, security-policy ## Description Your AI client connects directly to Okta Identity Cloud's core services. You won't need to click through admin dashboards anymore; you just tell your agent what you gotta do and it handles the rest of the heavy lifting. **Managing User Accounts:** You can list every user in the Okta Universal Directory using `list_users` for an organization-wide headcount. To check a specific person's details, run `get_user` with their explicit ID to pull their full profile and attribute data. If you need to shut down an account permanently, use `deactivate_user`; this immediately suspends and revokes all future sign-ins. For quick security measures, you can forcefully kill every active login session for a specific user by calling `clear_user_sessions`. **Group Membership & Access Control:** To understand your organizational structure, use `list_groups` to get a directory listing of every single group—whether it's a security group, an application group, or a dynamic one. You can then check the specific membership and attributes for any given group using `get_group`. If you need to know who belongs in a certain group, run `list_group_users` against that specified Okta Group. When dealing with applications, first use `list_apps` to see every service integrated into your dashboard, covering SAML, OIDC, and SCIM connections. For deep dives on an app's setup, you can retrieve detailed SSO configuration data—including client secrets or cert chains—for a single connected application using `get_app`. **Security Auditing & Logs:** When security is the issue, you need visibility. You pull the 100 most recent audit logs from Okta by calling `list_system_logs`. These logs cover everything: sign-in attempts, Multi-Factor Authentication (MFA) results, and any configuration changes that happen in the system. This gives your agent a central record for reviewing security events. If you're checking on who accessed what, you can combine this by listing all users with `list_users`, then cross-referencing their activity against the data pulled from `get_user` or the logs provided by `list_system_logs`. ## Tools ### clear_user_sessions Terminates every current login session for a specific user ID. Use this when you suspect an account has been compromised. ### deactivate_user Suspends and permanently revokes access for an Okta user account, blocking all future sign-ins immediately. Ideal for emergency offboarding. ### get_group Pulls all specific membership details and attributes for a designated Okta Group. ### get_user Fetches the full profile, status, and attribute data for an explicit Okta User ID string. ### get_app Retrieves detailed SSO configuration data—like client secrets or cert chains—for a single connected application. ### list_groups Provides a comprehensive directory listing of every security, application, and dynamic group in your organization's Okta setup. ### list_users Lists every single user configured in the Okta Universal Directory for organization-wide reporting purposes. ### list_system_logs Retrieves the 100 most recent audit logs from Okta, including sign-in attempts, MFA results, and configuration changes. ### list_apps Lists every application integrated into your Okta dashboard, covering SAML, OIDC, and SCIM connections. ### list_group_users Returns a list of all users currently assigned to any specified Okta Group. ## Prompt Examples **Prompt:** ``` Retrieve the user profile for 'mark@example.com'. ``` **Response:** ``` I found the profile for ID `00u12xxxxxxx`: Mark Johnson. The account status is currently `ACTIVE` and mapped to the 'Engineering' department. Would you like to check his group associations? ``` **Prompt:** ``` Clear all active sessions for user 'mike@example.com' immediately. ``` **Response:** ``` Success. I've sent the termination command to Okta. All active sessions for `mike@example.com` have been cleared and closed, forcing a re-login for any connected service. ``` **Prompt:** ``` List all active application mappings for the 'Contractors' group. ``` **Response:** ``` Scanning Group mapping ID `00xxxx` ('Contractors'): I found 3 provisioned apps tied to this cohort: 1. Slack (Provisioning Active) 2. Atlassian Jira Server (SAML) 3. Zoom (SAML) Do you want me to revoke any permissions immediately? ``` ## Capabilities ### Manage User Accounts Retrieve user profiles, create new identities, or mark existing accounts as deactivated. ### Audit Security Logs Pull recent sign-in attempts and audit events from the Okta system logs for security review. ### Control Sessions Forcefully terminate all active login sessions for a user, critical when a device is compromised. ### Manage Group Membership List all groups and check which specific users belong to them or what applications are tied to them. ### Check Application Access View detailed Single Sign-On (SSO) configurations, including client secrets and cert chains, for any connected application. ## Use Cases ### Investigating a Suspicious Login A security analyst notices an unusual login time. They ask their agent: 'Check the logs for activity on User X.' The agent runs `list_system_logs`, immediately showing if the user used MFA, from what IP, and if any suspicious configuration changes were made recently. Problem solved in seconds. ### Bulk Decommissioning The HR team gives a list of 50 terminated employees. The admin uses `deactivate_user` for all IDs in a batch script, confirming that access is cut off across every linked corporate app, preventing orphaned accounts from causing security holes. ### Auditing Departmental Access The compliance officer needs to know who has 'Admin' rights. They ask the agent to run `list_groups` and then target the specific group using `list_group_users`. This confirms every person assigned to that high-privilege role. ### Fixing a User Lockout A helpdesk tech gets an urgent call from a user who can't log in. Instead of walking them through the password reset portal, they ask the agent to `get_user` (to check status) and then run a credential reset command via the server. ## Benefits - **Stop Manual Log Checks:** Instead of manually navigating logs, use `list_system_logs` to pull the 100 most recent sign-in attempts instantly. You see who logged in, when, and if MFA worked—all without clicking a single button. - **Instant Offboarding:** When an employee leaves, don't wait for HR to manually update ten systems. Use `deactivate_user` to revoke all access across the entire Okta domain immediately. - **Deep User Profiling:** Need to know what department 'Jane Doe' belongs to? Running `get_user` gives you her full profile and status in one go, eliminating cross-referencing multiple internal systems. - **Group Access Auditing:** Don’t trust group names. Use `list_group_users` combined with `list_groups` to map exactly which users are assigned to a specific department group, ensuring compliance. - **Security Incident Response:** If you suspect lateral movement, use `clear_user_sessions` right away. This command forces every connected service to drop the user's session, stopping active threats instantly. ## How It Works The bottom line is you bypass manual UI navigation. You speak an administrative command to your agent, and it translates that into a secure API call for Okta. 1. Subscribe to the Okta MCP Server directory and provide your domain details and organizational API Key. 2. Instruct your AI agent with a specific command: 'List all users in the Engineering group.' 3. The server executes the request against Okta, returning a structured list of user IDs and their current status. ## Frequently Asked Questions **How do I check who is in a specific group using list_group_users?** You run `list_group_users` and pass the exact Group ID or name. It returns a precise, up-to-date roster of every user assigned to that group right now. **Can I find out if a user's session was terminated using list_system_logs?** Yes. `list_system_logs` captures all sign-in events, including when sessions were manually cleared or revoked. You can filter the logs by time and action type. **What is the difference between get_user and list_users?** `get_user` requires a specific user ID to pull that profile's details. `list_users` pulls a directory listing of every configured account in the entire Okta domain. **Should I use deactivate_user or clear_user_sessions?** Use `clear_user_sessions` when you suspect an *active* compromise and need to force a re-login. Use `deactivate_user` for permanent offboarding, as it revokes future access entirely. **How do I check the structure and list all available groups using list_groups?** It lists every configured Okta Group, providing an overview of your organization's directory policies. This is critical for understanding how permissions are structured across different security and application domains. **What does get_app provide regarding a specific integration? ** It pulls the detailed SSO configuration for any given app, including client secrets, X.509 certificates, and token-grant lifespans. This is essential when auditing security bindings or verifying connection health. **How can I list all integrated applications using list_apps?** This tool inventories every sign-on integration—whether it uses raw OIDC, SAML 2.0, or SCIM provisioning. It gives you a full picture of what apps your Okta tenant supports. **What information can I get about a specific group using get_group?** It returns the complete metadata and policy details for an individual group, not just who is in it. This helps you understand the explicit rules governing that department's access permissions. **Where do I retrieve my Okta Domain and API Token?** Log in to your Okta Admin Console. The Okta domain is simply the URL you use (e.g., `company.okta.com`). To get the API Key, navigate to **Security** -> **API**, then select the **Tokens** tab. Click **Create Token**, assign it a name, and securely copy the generated string. **Can the agent clear active sessions for a compromised user?** Yes! If you suspect an ongoing security incident, you can promptly ask the agent to clear user sessions (`clear_user_sessions`) by simply stating the user's ID or email. The integration talks back to Okta and terminates persistent connections instantaneously. **Is the administrator API key shared globally with anyone else?** No, your setup is extremely private and BYOC (Bring Your Own Credentials). The token is entered locally inside your private environment or workspace instance and injected tightly and exclusively into your isolated runtime execution. It is never exposed publically.