Table of Contents

Foundational Questions

What is Identity Threat Protection?
What specific problems or challenges is Okta solving for customers?
How do Okta customers solve these problems today?
What key capabilities and benefits are we offering? 
What are the main use cases? 
What is our unique differentiation?
Is Identity Threat Protection a good fit for my organization?
What applications will be supported for Universal Logout?
Why is it called Universal Logout if only certain apps are supported? 
When is support coming for Universal Logout for Office 365? 

Technical and Architecture Questions

How does continuous risk assessment in ITP enhance app access security in Okta?
What are Login, Session, and Entity Risk? 
What is SSF? 
How are shared signals used by Okta? 
Who are our current signal-sharing partners? 
What are the differences between Okta Verify device signals and Shared Signals Framework? ​​​​​​​
Is Microsoft leveraged as part of the Shared Signals integration?  ​​​​​​​
What is CAEP?  ​​​​​​​
How do we distinguish between threat actors using the same IP address?  ​​​​​​​
​​​​​​​How Does Okta Handle IP-Chain (X-Forwarded-For) Changes (for example in proxy/Zscaler environments? ​​​​​​​

Foundational Questions

What is Identity Threat Protection? 

Identity Threat Protection with Okta AI (ITP) is a new Workforce Identity Cloud (WIC) product that provides continuous evaluation of user risk and authentication policies throughout active sessions to detect identity-based threats such as session hijacking attempts and compromised accounts. Powered by machine learning and broad signal ingestion from an organization’s best-in-breed security stack, it extends observability beyond initial authentication to any time after a user is logged in. This enables real-time detection, and inline response to attacks at the identity layer.
 

What specific problems or challenges is Okta solving for customers?

• Gaps in continuous risk monitoring after initial authentication. Okta continuously evaluates risk signals throughout user sessions, providing real-time assessment and enabling timely response to dynamic risk changes post-authentication. This comprehensive approach to risk management supports Zero Trust initiatives.

• Fragmented risk insights across diverse security tools and systems. As a universally deployed Identity Provider with control over the authentication session, Okta performs comprehensive, continuous risk assessments by leveraging signals from the customer’s broader tech stack to strengthen protection against identity threats.

• Balancing risk mitigation with the user experience. By evaluating a variety of security indicators – like unusual login patterns and behavior anomalies –from across an organization’s tech stack, Okta allows organizations to tailor risk mitigation to specific threat levels. This optimizes both security and user experience through flexible authentication flows that protect against sophisticated threats, while ensuring a seamless user journey.

• Decentralized and highly manual threat detection response. Okta empowers organizations to leverage risk events to rapidly initiate automated workflows that remediate threats in real-time. This simplifies identity threat detection and response compared to over-reliance on manual processes that slow reaction times.

How do Okta customers solve these problems today?

Current workarounds include:

• Ineffective continuous risk monitoring. Rely solely on initial authentication, leaving sessions unmonitored post-authentication with no capabilities for detecting changes in risk or user context

• Disconnected security tools. Use siloed security tools lacking integration, resulting in fragmented visibility and inability to correlate signals across systems.

• Disruptive risk mitigation. Shortened session lifetimes and repeated MFA prompts for any risky activity imposes excessive friction on users, especially low-risk scenarios.

• Manual and reactive threat response. Vendor lock-in, siloed security, and reliance on manual processes for threat response delay remediation after the fact, increasing risk exposure.

What key capabilities and benefits are we offering?

What is the difference between “Single Logout” and “Universal Logout”? 

Single Logout is a user-initiated flow that allows a user to log out from all services in a federated identity system at once. Okta does not support this in full; rather, it allows the Service Provider to initiate a logout at the IDP layer (Okta), not at all other Service Providers. Single Logout is usually managed by browser redirects and has historically been pretty unreliable.

Universal Logout, on the other hand, is an admin/system-initiated flow that uses app-specific APIs to directly terminate application sessions for a specified user directly. This doesn't involve the browser and so can be triggered at any time to terminate all sessions - most commonly in response to a detected threat or increased risk.

Universal Logout requires specific integration and can only work with apps that provide APIs for session termination. Part of the proposed IPSIE standard involves defining a standard for the session termination API to make interoperability easier.

Why is it called Universal Logout if only certain apps are supported? 

The "universal" term indicates this capability differs from single logout, where we take action against a single app session cookie or within the context of one app. With Universal Logout, we are steadily expanding support through standards-based methods like OIDC backchannel and integrations to achieve logout across a growing ecosystem of apps we already integrate with. While starting with a subset of partners, we’ll continue expanding over time to realize the full vision of Universal Logout. 
 

When is support coming for Universal Logout for Office 365?

With Universal Logout, we are steadily expanding support through standards-based methods like OIDC backchannel and integrations to achieve logout across a growing ecosystem of apps we already integrate with. While starting with a subset of partners, we’ll continue expanding over time to realize the full vision of Universal Logout. 

Technical and Architecture Questions

How does continuous risk assessment in ITP enhance app access security in Okta?

Challenges with traditional app access authorization

In a typical configuration, Okta uses the Global Session Policy (GSP) and Authentication Policy (Auth. Policy) to authorize initial access to resources. Post-initial login, Auth. Policy re-evaluates during access refresh or single sign-on (SSO) for subsequent applications. This leads to challenges in:  

Policy Coverage: Maintaining individual Auth. Policies for each application introduce administrative overhead, often leading to reliance on GSP as a universal security layer.

Engine Migration: Organizations transitioning from the Classic Engine to the Okta Identity Engine (OIE) frequently depend on GSP as their foundational security mechanism.

Static Evaluation: The GSP is not re-evaluated with each resource interaction, thereby missing dynamic contextual changes, such as IP address shifts, that could influence the risk profile.

Continuous assessment in Identity Threat Protection

Identity Threat Protection with Okta AI incorporates continuous risk assessment into adding an adaptive, real-time layer to security protocols, strengthening the overall integrity of application interactions. Key advantages: 

Persistent policy re-evaluation: GSP and Auth. Policy are both subject to continuous assessment throughout the user’s session, ensuring a perpetual security posture.

Contextual risk assessment: Any change in the contextual elements (IP address, session risk, user behavior, etc.) triggers a re-evaluation of the associated risk metrics, providing a more granular and dynamic risk assessment.

Extended intelligence: By ingesting third-party signals (e.g., from Jamf), in addition to 1st party signals from Okta enhances the accuracy and robustness of our risk assessment algorithms.

Mitigation of Session Hijacking: The continuous re-evaluation of GSP negates risk vectors associated with session cookie theft.

On-demand MFA: Anomaly detection through continuous assessment enables the immediate triggering of additional authentication mechanisms inline like MFA.

What are Login, Session, and Entity Risk? 

Identity Threat Protection evaluates three types of risk. 

Login Risk refers to the risk calculated at the initial point of authentication, similar to assessing risk when logging into a banking website. 

Scope: Restricted to the point of login

Signals: Primarily initial authentication signals like device, location, etc.

Use-case: Protect against unauthorized access at the entry point.

Session Risk expands on Login Risk to continuously reevaluate the probability of compromise throughout an active Okta session, like a bank monitoring a user's activity after login for suspicious transactions. Session Risk is scoped only to the current session.

Scope: Confined to a particular session

Signals: Any interaction with Okta during the session, potentially including third-party signals

Use-case: Detect and react to suspicious activities that occur post-login within a session.

Attributes:

• Risk Level: Low, Medium, High, based on an internal session risk score.
• Risk Reason: Categorizes the type of attack or suspicious activity detected.

Entity Risk introduces a new paradigm by evaluating risk across the entire spectrum of a user identity, like an individual's credit score. It provides a holistic assessment of the probability a user account is compromised aggregated across sessions, devices, and apps - like a persistent user trust score.

While Session Risk is confined to one session, Entity Risk aims to calculate risk across multiple sessions and even multiple devices. An "entity" refers broadly to any object that requires an identity—this could be a user, device, or even an application. For now, the focus is on "Entity User Risk," which considers the entire risk surface related to a user's identity.

Scope: Not confined to any particular session or device

Signals: All threat surfaces intersecting with the user identity, including device, application, network, and data.

Use-case: Broad, ongoing risk assessment for an identity across various facets and touchpoints.

What is SSF?

The SSF (Shared Signals Framework) is an asynchronous publish-subscribe framework that we leverage in Identity Threat Protection to ingest signals from the security ecosystem. SSF is an open protocol that standardizes the flow of security Events between Transmitters and Receivers. This enables Okta and its Shared Signal Partners like Palo Alto Networks and Jamf to exchange real-time risk data across various threat surfaces, including networks, applications, and cloud environments. 

In SSF, an entity can be a transmitter or receiver. A transmitter is a system that sends out security event information to other vendors. For example, Okta can transmit risk data to Apple Business Manager (a receiver), allowing it to make informed security decisions. On the flip side, an SSF Receiver is a system that accepts and acts on these security events. In the context of Okta and Netskope, Okta serves as a receiver, getting information from Netskope about suspicious activities. 

By adopting SSF's open, protocol-centric approach, Okta enhances scalability, flexibility, and interoperability, ultimately elevating the security ecosystem and allowing customers to leverage their existing investments.

Learn more about SSF.

How are shared signals used by Okta? 

Any detection event from our integration partners configured with Identity Threat Protection will fire a generic "Partner Reported Risk" event to Okta with either an increased or decreased risk level. Okta admins can take action on this event via Workflows, Entity Risk Policy actions, and other methods. Specific 3rd party partner use cases are also in development to demonstrate the value they provide. For now, any detection by a launch partner will trigger a Shared Signals event.

Who are our current signal-sharing partners?  

For the Early Access release, we are targeting the following partners who will contribute to the shared signals pipeline: