One Clayton Christensen point that I’ve harped on several times before is that as integrated structures within a value chain disaggregate into their modular components, new points of integration emerge to sweep value. In the context of public cloud infrastructure and the range of tools and apps flourishing on top, you might think of solutions that organize the resulting fragmentation…Kubernetes orchestrates clusters across compute environments; Mulesoft manages APIs and integrates applications; and Okta, the main subject of this post, manages user identities across applications. At its core, Okta’s value proposition consists of two parts: 1/ a directory that stores user profiles (Okta’s Universal Directory) and 2/ a Single Sign-On portal that grants authenticated users access to a range of applications with a single username and password, obviating the collection of usernames and passwords that an employee might otherwise keep.
UD and SSO complement a third important product, Lifecycle Management, which allows customers to quickly onboard workers when they are hired and deactivate them when they are no longer employed. In between, as an employee’s roles and privileges change, so should the apps he is authorized to use. When handled manually, granting entitlements to different apps might mean going through dozens of steps, a laborious process prone to insidious entitlement creep (where a user, in transitioning to different roles, is unwittingly granted more privileges than he needs to do his job), especially when considered against a base of 10,000+ employees, a large percentage of whom are turning over and switching roles at any given time. Much easier to have a single system like Okta that automatically provisions and deprovisions access as roles and job titles change1.
Over time, Okta’s integrations have gotten broader, spanning ever more applications, and deeper, communicating workflow activity between connected apps (for instance, a security issue detected in Splunk prompts Okta to elevate authentication protocols, which sparks a ticket in ServiceNow). Its growing adoption as an identity standard in the cloud mirrors Active Directory’s dominance on-prem. Some companies have now mandated that their software and security vendors be pre-integrated into Okta’s Integration Network2, compelling more vendors to plug-in and incenting more systems integrators to provide support, in turn rendering Okta more useful for enterprises to adopt, drawing still more vendors and deeper integrations.
A system that serves as the central repository of employees and the applications they use inevitably touches security and compliance use cases. With cloud applications dispersed across so many different environments and accessed by so many different users through devices running a variety of operating systems, security should not be restricted to a dissolving corporate perimeter but rather tethered to “edge” constituents…endpoint devices and users3. And as over 80% of breaches involve compromised credentials, who better to implement access policies than a company that – by virtue of holding a single record of millions of users, logging in on at least as many endpoints, producing billions of authentication instances – has granular insight into who is trying to access what and from where, data points that can be used to flag abnormal behavior like “Bob from HR” trying to access Workday in the middle of the night from China (fun fact: nearly half of all attacks at Okta’s cloud authentication layer are coming from China). Okta can leverage intelligence across its entire user base – like repeated log-ins from what its security team has determined to be compromised IP addresses – to better protect each of its enterprise customers. So, cross-side network effects in Identity (enterprises <-> vendors) delivers sharper signaling data to Security.
The things I’ve talked about so far – common identity layer across apps + security – are used by internal constituents like employees. This Workforce Identity market is substantial, but turning identity functions outward, as Okta has done over the last 5 years, toward an enterprise’s customers and partners, offers an opportunity that is at least as vast.
To provide some background on this point, in a prior post I wrote:
“An extension of disruption theory (as expounded upon in Christensen’s The Innovator’s Solution) is helpful here: integrated architectures, made up of tightly unified proprietary interdependent components, are best suited to optimize performance and tend to dominate until a product becomes functionally “good enough” to meet the market’s needs, at which point other vectors of competition – convenience, flexibility, speed to market – become more important and call for standardized, independent pieces that comprise a modular architecture
… in the context of computing, consider (broadly) the trek from mainframes [chips, hardware, operating system, and applications all fused together] to Wintel [hardware and chips modularized but OS and applications integrated] to enterprise cloud [hardware, chips, OS, and applications all modularized]. And increasingly, applications themselves are disaggregated into independent functions that communicate through APIs…”
Twenty years ago, it probably wouldn’t have made sense to fashion a whole company around, say, a payments function whose primary interface was an API. You would not have found enough customers for it. E-commerce was a budding opportunity with uncertain prospects. But as the internet matured, online commerce got big enough to justify the creation of companies whose sole purpose was selling the constituent pieces of what were hitherto fully integrated solutions. Today, there are 10s of thousands of public APIs. Rather than devote scare developer resources to building generic but important features, an enterprise can simply consume best-of-breed third-party versions. Stripe, SendGrid, Twilio, and Okta offer functions whose use cases are common and generic enough (payments, email, messaging, and identity/authentication, respectively) that they can be built once – by a company whose only job is optimizing that function – and embedded across countless applications4.
The per-user economics of Okta Customer Identity are not quite as compelling as Employee Identity – what an enterprise pays Okta is based on an estimate of monthly visitors rather than on the total number of consumers in the database, and the price per customer MAU pricing is far lower than the per employee pricing of Employee Identity – but the TAM is unconstrained. It’s hard to think of a domain where identity doesn’t play a critical role.