How to Secure the SaaS Apps of the Future

Karl McGuinness

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.

Requirement

Standard

Requirement Statement

Okta Support

Single Sign-On

OIDC (OpenID Connect)

SaaS applications must support Single Sign-On using a protocol that can protect privileged operations in the application with phishing-resistant re-authentication provided by the Identity Provider.

Modern, best of breed applications using the Okta Customer Identity Cloud (Auth0) and the Okta Workforce Identity Cloud support OIDC.

Both platforms support transactional MFA.

Passkeys

FIDO2 WebAuthn

Break Glass Accounts (non-Federated accounts) in enterprise SaaS applications must be protected by phishing-resistant factors to thwart common credential-based attacks. 

Passkeys are supported as the primary authenticator in both the Okta Customer Identity Cloud (Auth0) and the Okta Workforce Identity Cloud 

User Provisioning and Deprovisioning

SCIM (System for Cross- domain Identity Management)

SaaS applications must support industry standard approaches to the automated provisioning and deprovisioning of users.

Okta Lifecycle Management uses SCIM to automate user lifecycle management.  Applications built on the Okta Customer Identity Cloud (Auth0) can be managed by any SCIM compatible client such as the Okta Workforce Identity Cloud

Role and Entitlement management

SCIM Roles and Entitlements Extension

SaaS applications must support centralized identity governance mechanisms that ensure users are only provided the minimum  permissions required for their role at any given time.

Okta Identity Governance can manage user entitlements within the world’s top SaaS applications. 

Application Logs 

REST APIs

SaaS applications must offer programmatic access to logs that can be streamed in real time.

Logs should capture all security-relevant events. Events should be well documented and presented in a structured, industry-standard format. All distinct fields should be able to be programmatically parsed.

Okta Log Streaming offers access to Okta log events in close to real-time for both the Okta Customer Identity Cloud (Auth0) and Workforce Identity Cloud 

Dynamic Access Management 

Continuous Access Evaluation Profile (CAEP)

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

At minimum, applications need to publish and subscribe to the following events:

Session Revoked

Credential Change

Okta Identity Threat Protection can publish and subscribe to CAEP-compliant events. 

Universal Logout

Global Token Revocation

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

Our roadmap supports Universal Logout across all Okta applications.

API Access Standards

OAuth 2.1

SaaS applications should implement OAuth 2.1 based access to their APIs 

OAuth is the industry standard for secure API access and supports both user delegated and non-human service based access mechanisms.

Sender Constrained Tokens

Demonstrating Proof-of-Possession (DPoP)

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

The Okta Workforce Identity Cloud supports DPoP and requires it by default for new API Service Integrations. Okta’s roadmap includes plans to embed DPoP for new B2B SaaS apps in the Okta Customer Identity Cloud (Auth0).

Security Best Practices

OAuth2.0 Security BCP Browser-based Apps BCP Native and Mobile Apps BCP

JWT Client Authentication and Authorization Grants

SaaS applications should support agreed Best Current Practices agreed by IETF.

Okta personnel are contributors to many of these Best Current Practice materials.

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.

Karl McGuinness
Chief Product Architect, Okta

Karl McGuinness is Chief Product Architect at Okta where he is responsible for product strategy, architecture, and identity standards. He has over 20 years of experience in the identity industry building and scaling market leading products and infrastructure. Karl is actively involved with the identity community developing and adopting technical standards that provide the foundation for the Okta Identity Cloud.