Single sign-on: How Okta is building an online identity platform
There comes a time when technology companies need to make a decision: do they want to become an essential service that no-one can do without, or do they want to become the platform everyone builds on top of?
It’s a hard transition to make. You can argue that it’s one that Adobe has tried to make several times, the latest attempt being its Flash-based web development tooling Flex. It’s one that Twilio is well on the way to making, along with Paypal and Box.
Now it’s the turn of Okta, which is taking its cloud-hosted single sign-on service and using it as the basis for an identity platform. With identity at the heart of most cloud services, one place to manage and control and aggregate the various aspects of our online identities makes sense, as part of a migration away from complex and insecure password-based systems to contextual services that are both simpler and more secure.
SEE:A winning strategy for cybersecurity (ZDNet special report) | Download the report as a PDF (TechRepublic)
It’s a big shift to make. Okta’s single sign-on SaaS product manages access to cloud services, controlling access to all the services a company might use from one password and one log-on tool. It’s an attractive alternative to separately managing access to Google G Suite, to Salesforce, to Box, and to whatever other tools and services you might be using. It also simplifies provisioning, assigning accounts as part of HR on-boarding, and removing or redirecting them when someone leaves.
Okta’s platform approach is very different, asking the question: “Why should every app have a different identity layer?”
Building on its existing single sign-on tooling, and open standards like OpenID Connect, it offers a way of using cloud-hosted user directories to handle application authorisation, holding user details and passing authentication tokens to and from the app. By simplifying OpenID operations, Okta aims to be a hub for our online identities (both B2B access to business apps and B2C access to the sites and services we use outside the office), offering access to password-less technologies like FIDO to simplify access even further.
At Okta’s recent Oktane event I sat down for a chat with Alex Salazar, the company’s vice president of developer platform, to talk about how it was approaching this transition, and the importance of developer relations and tooling to the process.
R&D required
Salazar began by noting that the intention was to make it easier for everyone by making it easier for developers. It might sound straightforward, but it’s not, as he pointed out: “A lot of R&D is needed, and we’re making the investments. Developer experience is a large commitment, one we’re clearly making.”
That means approaching developers where they are. At one end of the scale it’s a matter of offering simple tools that let applications tap into existing authentication and identity workflows, with UI as well as code. All you need to do is add your service APIs and swap out Okta’s branding for your own. At the other end of the scale, where you want to integrate at a deep level, that means offering well-designed, well-documented granular APIs that can help build the tools you need for your applications or services.
As Salazar points out: “No-one wants to custom build; it’s too expensive to build and way too expensive to maintain. But it’s hard to determine the level of abstraction that’s needed.”
Once you have a platform, there’s a lot more you can do than just deliver specific software. As more and more users build on the Okta tooling, there’s the option to take advantage of network effects and deliver a second-order level of tooling, like the contextual ThreatInsight service Okta announced at Oktane.
Salazar points to developer relations as a key element in this type of transition. “We’re educating developers on how to be successful,” he says. “Out of the box it works well, but we need deep granularity to work on the problems developers are trying to solve.” The developer-relations team feed back customer requirements to the Okta product team, making the process more collaborative inside and outside the company.
Platform transition and pricing
As a company Okta is fully aware of the transition it’s making. “We have a commitment top to bottom to being a platform,” Salazar notes, “and it is expensive and hard.”
With developers working on both IT and customer-identity products, and a leadership that Salazar describes as “making long-term bets,” there’s a lot to be done. One area that’s needed a lot of thought is how Okta prices its platform versus its identity services. The per-seat model associated with SaaS isn’t really suitable for developer tooling, but with API call-based pricing it’s also hard to go from a low-cost proof-of-concept to a full-blown product — especially when that means switching from developer to enterprise price plans.
SEE: Cybersecurity in an IoT and mobile world (ZDNet special report) | Download the report as a PDF (TechRepublic)
That dichotomy has led to the launch of a new pricing model, OneApp, which offers a lower cost approach for a single app. It has the same features and support as an enterprise plan, but it’s more attuned to developers who want to add identity features to an app or a service. If it becomes the basis for a family of apps, then there’s the option to switch to an enterprise plan.
“We see OneApp for the middle case,” Salazar says. “It isn’t free. But it is designed to be more affordable.”
There’s an alternate approach to OneApp for non-profit organisations or for early-stage companies. This lets you use the service and APIs for free, all you need to do is ensure that Okta’s branding is on authentication pages. “It’s great advertising, it gets people using our products, and it fits in with our commitment to everyone having a secure identity,” Salazar says.
Pitfalls
There’s another key issue that needs to be handled by Okta, and it’s one that needs a lot of care. If its platform is to be the de facto identity platform for the internet, then the company needs to avoid the pitfalls of its predecessors. Microsoft’s failed Hailstorm and the recent issues around Facebook’s Connect are obvious examples of how trying to be an identity provider can go wrong: failing through lack of trust or through overreach with user data.
Salazar is all too aware of the history of identity services, as he says: “We need to make doing the right thing easy; and it can only be done by example.” Okta’s role as an identity platform has significant responsibilities that need to be handled by the company and anyone wanting to use its services. “We are adamant about our role as steward of customer data,” Salazar notes. “We secure it as much as we possibly can. We have to lead by example to help lead the industry.”
READ MORE ON CYBER SECURITY
READ MORE HERE