Overview

Okta Access Requests provides powerful integrations with communication platforms like Slack and Microsoft Teams, enabling users to submit and approve requests directly from where they work.* This streamlines workflows and boosts end-user productivity. However, these integrations introduce a new security perimeter that requires careful attention.

This guide outlines key security risks and best practices to secure your Slack or Microsoft Teams environment.

Understanding the Risks

The convenience of chat-based integrations comes with security risks that may not be immediately obvious to an admin.

• Session Security: When a user takes action in Slack or Teams (that is, making or approving a request), they are using their chat application session, not their Okta session. Many organizations have more relaxed authentication policies for chat tools, which means the level of assurance for that action may not meet your organization's security standards. A compromised chat session could allow a bad actor to make an access request without needing to re-authenticate with Okta.

• Data Integrity: The integration relies on matching a user in the chat app to a user in Okta based on their email address. If these attributes are not strictly managed (that is, they can be edited by end-users or are not sourced from a trusted system), there is a risk of a user impersonating another to gain unauthorized access.

Steps Okta Has Taken to Secure the Integration

Okta has proactively taken steps to mitigate risks that a compromised chat session can be used to gain unauthorized access:

• Blocking Self-Approvals: Unless an approver is individually assigned, the integration is designed to block users from approving a request they submitted themselves. This prevents a compromised identity from being used to both submit and approve their own access request and self-escalate.

• Requiring Okta Session for Okta Admin Roles: Requests for Okta admin roles using our Govern Okta admin roles feature cannot be submitted or approved from chat applications. With this feature, any request for a highly privileged Okta admin role must be requested from the Okta Dashboard and approved in the Okta Access Requests application, thus enforcing that a valid Okta session exists for both actions. This ensures that these sensitive actions are subject to your strongest authentication policies.

Best Practices to Secure Your Environment

By implementing these best practices, you can dramatically reduce risk and maintain a strong security posture while still benefiting from the Okta Access Requests Slack/Teams integrations.

• Enforce Strong Authentication and Session Policies: The security of your Access Requests in Slack and Teams is only as strong as the security of the chat application itself. Configure your Slack and Teams Application Authentication Policies to enforce more frequent re-authentication to mitigate the risk of a compromised, long-lived session. Additionally, for your most critical applications, ensure that you have strong authentication policies in place that require users to re-authenticate frequently and use strong factors like phishing-resistant MFA so that, even if a bad actor were able to get approved for unauthorized access through Okta Access Requests, they would need to meet a high level of assurance to actually use that access.

• Enable Universal Logout (UL): For applications that support it, Universal Logout ensures that sessions can be terminated immediately if a risk is detected. See Third-party apps that support Universal Logout for the list of third-party apps that support Universal Logout. Universal Logout is currently supported for Slack Enterprise's Slack account and can be configured to invoke session termination upon risk detection. 

• Centralize Your Data Source: Ensure that critical user attributes like email addresses are synced from a single, authoritative source like a Human Resources Information System (HRIS) or Active Directory. Configure your chat app's settings so that users cannot edit their own email addresses. This prevents a bad actor from impersonating another user to bypass an approval workflow.

• Enable the Unified Requester Experience: With the Unified Requester Experience, all requests are ultimately redirected to the web for submission and thus require a valid Okta session. While approvals can still be done in Slack, this change eliminates the highest risk vector for a bad actor to gain unauthorized access. The Unified Requester Experience ensures that an Okta session is always part of the journey to obtaining access, reinforcing your security posture.

By following these recommendations, you can confidently deploy Okta Access Requests chat integrations, knowing you have minimized potential risks while maximizing productivity for your end-users.

*Only requests built with Request Types can be submitted directly from Slack/Teams. Requests built with both Request Types and Request Conditions can be approved directly from Slack/Teams.