Over the past few years we’ve observed a fundamental shift in the threat model for highly targeted organizations.

Today, if an attacker can’t manage to steal user credentials for highly targeted organizations, they will pivot to instead stealing a user’s proof of authentication.

Attackers will use malware to steal session tokens from a user’s browser after they sign in. They may similarly use transparent proxies to steal session tokens from a user’s browser after they sign in. And as Okta’s recent experience shows, if bearer tokens of any kind are stored unprotected, attackers will sniff them out. Stolen session tokens can often be replayed in a browser of the attacker’s choosing for the remaining duration of the user session.

For several years Okta has contributed to internet standards that aim to mitigate the theft and replay of session tokens. We are taking these actions because we cannot assume that the current solutions to these problems (endpoint protection and phishing resistant authentication) will always be applied effectively. It is prudent to assume that some malware will go undetected by endpoint protection solutions, or that some users will sign in to applications without the protection of phishing-resistant authenticators. When either of these events happen, defenders require an ability to limit the blast radius from a stolen session token.

Our goals here are threefold:

• We need to constrain the use of tokens that are for specific devices, clients and/or locations,

• We need the identity ecosystem (identity providers and SaaS applications) to autonomously exchange signals about changes in session risk, and

• We need the means to act on identified changes in session risk: such as forcing step-up authentication within the context of an application, or signing a user out of all of their application sessions.

Okta has demonstrated, in response to an October security incident, that modern applications supporting OIDC (OpenID Connect) can meet many of these goals. Okta now binds Admin Sessions to location (ASN, by default and optionally by IP), forcing re-authentication when an administrative user changes location mid-session or attempts to perform critical, security-sensitive tasks.

The next challenge for Okta is to apply the same hardening techniques used for the Okta Admin Console to the innumerable third-party SaaS applications that our customers gate behind Okta.

We have laid the groundwork for several innovative new features that every enterprise SaaS application needs to embrace to protect users in the era of post-authentication attacks.

Enterprise-ready requirements for today’s SaaS apps

Today there are a handful of non-negotiable requirements SaaS applications must meet before a Chief Security Officer (CSO) would consider them to be enterprise-ready.

• Single Sign-On (via support for OIDC or SAML)

• User Provisioning and deprovisioning (via support for SCIM)

• Programmatic access to logs (using REST APIs)

However, most CSOs haven’t updated the requirements they demand from SaaS applications for at least 5-10 years. And during that time, we have observed fundamental changes in both the nature of the applications we are protecting, and in the threat posed to SaaS applications from post-authentication attacks.

Enterprise-ready requirements for the Apps of the Future

Today’s SaaS application is typically more than a simple web app. For example, consider Slack. Slack is a distributed set of apps and services, encompassing both web and native application experiences, and integrated with other applications (e.g. Google Workspace, Atlassian Confluence and Jira) using OAuth. Securing these distributed applications requires a new, longer list of requirements. SaaS applications will (at the very least) need to support the three features detailed below to pass muster with CSOs.

1. Proof-of-possession

Proof-of-Possession is a method of constraining the use of OAuth access tokens to an authorized client (browser-based app).

It prevents attackers from replaying a stolen token from any other client.

Okta has addressed this requirement via our support for Demonstrating Proof-of-Possession, an OAuth 2.0 extension that developers of SaaS applications can use to cryptographically bind a token to an authorized client. If an access token issued to one client is intercepted by an attacker, and replayed on any other client, the SaaS application can deny access.

There are a few logical reasons why this problem should be solved at the application level using DPoP. Previous efforts to solve this problem at the transport level (using mTLS-based token binding) have encountered scale, deployability and usability challenges. Trusted Platform Modules (TPMs) have historically not been fast enough to sign a proof for every HTTP request, and end-to-end proofs are also problematic in enterprise environments where proxies and other intermediaries terminate TLS.

DPoP, by contrast, will reduce the risk of a stolen token across the broadest possible number of modern native apps. Okta has enabled DPoP by default in all API Service Integrations that access Okta’s management APIs. Once configured, Okta API endpoints will require the bearer of a token to prove this cryptographic relationship to an authorized client.

Chief Security Officers should be demanding that SaaS applications do the same. Consider the following requirement in your vendor security questionnaire:

SaaS applications must require cryptographic proof that a client presenting an access token was authorized (demonstrating Proof-of-Possession).

2. Continuous Access Evaluation Profile (CAEP)

Okta recently reduced the default maximum duration and idle duration for administrative sessions in Okta in an effort to shift the industry towards “secure by default” principles.

Counterintuitively, the default session for most SaaS applications is getting longer.

From a security perspective, organizations can only afford to extend the life of application sessions if security teams are confident that they can detect changes in user risk mid-session, and in near real time, orchestrating immediate responses to those signals in ways that don’t create excessive friction for legitimate users.

Continuous Access Evaluation Profile (CAEP) offers a path forward. CAEP provides a standardized way of ensuring that a change in session risk identified by one SaaS application can autonomously create responses in every other SaaS application accessed by the user via their Identity Provider.

Today, there are numerous risk signals Identity Providers like Okta can observe in relation to changes in user and session risk. But these signals aren’t always observable by the downstream SaaS applications accessed during an Okta session. SaaS applications can also observe changes in user and session risk, and again, many of which aren’t always observable to the Identity Provider.

Continuous Access Evaluation profile (CAEP), which uses the Shared Signals Framework standardized by the OpenID Foundation, is a publish/subscribe mechanism for describing changes in user, device, or session risk. Okta has built the necessary components to be a transmitter, receiver and aggregator of risk signals between applications, and is building an ecosystem of SaaS applications and security providers to exchange signals with.

Risk signals are already published and acted on by customers using Okta Identity Threat Protection in limited early access. Now is the time for CSOs to demand SaaS applications support the same risk sharing standards. Consider the following requirement in your vendor security questionnaire:

SaaS applications must be able to transmit and subscribe to risk signals using open, industry standard frameworks.

3. Universal Logout

With all the signals being exchanged using CAEP, security teams also need the ability to automate responses to heightened session risk.

One possible response would be for the SaaS application to trigger re-authentication when responding to a change in session risk.

If the observed risk meets an appropriately high threshold, the user’s IdP (Identity Provider) session and each of the user’s individual sessions with SaaS applications need to be revoked.

Up until now, there hasn’t been a simple way to do this. Single Logout (SLO) offered a partial solution. A user can log out of a SaaS application that supports SLO and be automatically signed out of their Identity Provider (IdP) session. The missing piece was a method of revoking ALL the connected SaaS applications a user authorized during a IdP session, including native apps and SaaS integrations.

Enter Universal Logout, a standardized method Okta has proposed to handle the “Single Sign-Out” problem. Universal Logout saves SecOps personnel the hassle of manually identifying and signing out users from each SaaS application accessed during a risky session.

CSOs need to demand that SaaS applications publish a Universal Logout endpoint to facilitate this process. Consider the following requirement in your vendor security questionnaire:

SaaS applications must publish a standard interface for revoking access to an application, including OAuth tokens.

How do these requirements move the needle?

When more applications meet these requirements:

• Users can only authenticate to an enterprise resource with a phishing-resistant authenticator from the right device(s),

• Applications will only accept requests from the right users with the right permissions,

• Sessions/tokens for web or native apps can only be used from the same device authorized to access them,

• Long-lived sessions are continuously re-evaluated for risk using signals from the enterprise and the application,

• All access from all devices can be terminated in real-time to limit the blast radius of a stolen session.

As the world’s largest independent and app-neutral Identity Provider, Okta is positioned to help organizations and application service providers meet these requirements.

Okta has the unique position of being able to influence the ability of the next generation of SaaS applications to enable these features with the check of a box (in the Customer Identity Cloud), and to provide a market for the next generation of B2B SaaS applications to reach workforce users via the Okta Integration Network. Okta has also enabled application integration wizards to help SaaS applications to retrofit these features.

Security teams need to demand more from the SaaS ecosystem to solve these fundamental security challenges.

SaaS Apps of the Future - Requirement Statements

A more expansive list of requirements for SaaS applications is provided below.

Okta is helping to incubate several other identity standards that were deliberately omitted from this list, given that they are not yet actionable by security teams. The emerging work in W3C around Device Bound Session Credentials is most interesting, as it brings proof-of-possession properties to browser-based session cookies; which is the final piece in the puzzle for protecting modern apps.