Okta Wants to Be an Identity Service for Developers

If you’ve come across the Okta set of cloud identity services, you’ve probably thought about it as an IT tool. Administrators can use it to manage logins to multiple cloud services like Office 365 and Google Cloud and Salesforce through a single interface, complete with policy on password strength and who can get access.

But Okta is also making more of its authentication and user management available through APIs so developers too can build these services into their apps, much like they would with API-driven identity services like Twilio’s Authy, Auth0, and Microsoft’s Azure Active Directory B2C.

With data security so important (and data breaches caused by poorly managed credentials so ubiquitous), it’s time to stop building poorly encrypted user and password systems (or copy and pasting code from Stack Overflow that does nothing more than base64-encode the password). Get a password reset system wrong and millions of account details can be lost. Just as Twilio APIs for messaging and communications and Stripe or Braintree APIs for payment, identity management is becoming a commodity it’s better not to write yourself.

“The urgency of everyone having to build customer web applications and take their products and services online mean there’s a big push to deliver and there just aren’t enough developers to do it,” Okta’s vice president for the developer platform Alex Salazar told the New Stack. They go for the path of least resistance and that is not always the best, most secure, most maintainable option; we’re trying to change that by having a good developer experience.”

That’s not just about the technology in Okta’s service, he maintained, but also the APIs and documentation for them. “We see documentation as product; we can’t announce [something new] until there’s documentation. It’s the same with SDKs; if something isn’t in the SDK and framework, it doesn’t exist,” Salazar said.

More Factors, More Complications

Passwords and usernames aren’t enough for security and user management for your apps these days. Increasingly, users require multi-factor authentication, which, for an increasing range of devices can be quite complicated to deploy. Even developers who turn to open source software such as the OAuth specification and the OpenID Connect protocol to simplify secure connections face an uphill task, Salazar said.

“If you know anything about identity, you probably know about OAuth. The problem is that implementing standard OAuth is actually not the best path. Even if you’re using fully compliant libraries that are maintained by a major vendor, you’re still missing out on security best practices most developers don’t know about,” Salazar said.

OAuth uses tokens to make it harder to intercept and replay credentials, and those must be used correctly; like not using an identity token as a session token because it might contain personal information, or not using an embedded web view in a native app to authenticate users because then they have to re-authenticate every time they use the app, because that embedded flow runs in a sandbox that doesn’t know they’re already logged in.

Developers also need to know how to handle flows like an assurance about how users have authenticated, and token revocation, he pointed out. “If your app is using tokens and you’ve got a delinquent or malicious user, you want to turn them off. The OAuth spec doesn’t talk about that so now you have to build out your own custom scheme of token revocation,” Salazar suggested.

Often, developers don’t even know this is a problem until it rears its head in production and then many don’t really have standard patterns on how to remediate the issue.

To help with that, when a developer signs into Okta they can pick what kind of app they’re developing and get templates and quickstarts that show what steps are involved for secure registration, email verification and password reset (and there, workflows are being added).

“We try to put you on the right path to make the best choices without you having to do too much extra work,” Salazar told us. “We’re targeting the most popular backend and front-end languages.” Libraries for Node/Express, Java/Spring, and ASP.NET to support developers building applications that run on the server, as well as for Angular and React on the front end side, and for iOS and Android as well. For other technologies, Okta offers documentation on using the APIs.

Okta has also created an embeddable, customizable JavaScript sign-in widget using its APIs that you can use to get an end-to-end sign in code flow, including multifactor authentication, password expiry and self-service account recovery that supports social authentication providers.

Another big move is that Okta is no longer just for user management in first-party apps; it can be used for customers as well as internal users, and it will soon support developers writing third-party apps. So if, say, a solar roof installer that uses Okta for customer identity has so many users that other developers want to write an app for them to use, they’ll be able to use those Okta identities in their app. Okta is also integrating with a wide range of cloud email services and OpenID Connect providers.

Multifactor authentication is now included in all Okta subscriptions, with one-time passwords delivered by email or along with detecting common passwords and blacklisting of IP addresses known to be malicious. A service like Okta lets you offer multifactor authentication without having to have your own infrastructure, and the quick starts are designed to make it easy for developers to implement as well.

“The problem with multifactor authentication is that it’s complicated,” Salazar said. “It needs to be more convenient; if you don’t make it easy for people to implement, it’s not going to get used. It also needs to be a good experience. If it’s not a good experience no one turns it on, and you need users to adopt multifactor authentication. Too many developers grab something insecure and don’t make it easy for end users.”

The next step is “passwordless” authentication, which services like Yahoo and Google already offer. One Australian insurance company is already using Okta to do that; because customers don’t log in enough to remember a password, they just use their email address to login — triggering a test message with a one-time token. Okta is working on a workflow for developers to deliver that. “Over the next 13 months, we will deliver a solid passwordless experience to customers, and also make sure it’s secure,” Salazar told us.