Okta API lead: how to secure the API economy

Smooth sailing on stormy seas?

Yet it’s far from smooth sailing. Developers have often built with a feature-driven mindset, where functionality has taken precedence over security, but in today’s security landscape where vulnerabilities and threats lurk at every corner, this must be turned on its head. Put simply, the growth of APIs needs to be matched with the mindset of securing them.

The fear over API security is not unwarranted.

Privacy and security issues stemming from API development is continuing to rise, so much so that according to Gartner, by 2022 the largest source of data breaches will arise from this. But without a deliberate, focused effort to protect these systems, even that timeline seems optimistic.

There are a number of approaches to API security that businesses take. Unfortunately, the most common is to trust end users either deliberately by having minimal security or implicitly by assuming no one will find the API. But, unqualified trust does not equal security in any circumstance, even for internal APIs. We live in a Zero Trust world where not treating API security seriously will leave companies open to being the next Equifax. Developers should approach APIs in the same way they would for web interfaces and applications to protect company data and IP.

To many, API keys are the answer. They provide additional security to selectively trusting end users and have the additional advantage of being fast and easy to implement. But, they allow all or nothing access, which may expose sensitive data to any developer that has your keys. We need to be smarter and only grant access to the things someone needs to accomplish the task at hand.

Taking protection further

One of the more advanced ways to protect an APIs’ infrastructure is an API Gateway.

With a full access management solution to complement it, API Gateways can be extremely valuable. But, when used alone, API Gateways do not give businesses full context on the user and how much we should trust them. They lack the ability to differentiate between a user on the trusted computer at their office versus a suspicious mobile device on the other side of the world. For example, using an HR system’s API to download holiday history contains a very different risk to using that same API to change direct debit information.

There is another approach that businesses should add to the mix – the industry standard, OAuth 2.0. It works like a hotel check-in experience; so key cards provide access to an application. Specific access tokens, granted by an Authorisation Server upon proof of identity, allow access for the specified user to a specific subset of resources, with an automatic expiration.

OAuth is a more complex approach but allows far greater flexibility and consistency – an unquestionable benefit in the world of security. It’s important to remember, however, that OAuth 2.0 is still not a complete solution for securing APIs because it does not address how to protect the API’s infrastructure itself.

Just like any other system in our infrastructure, we have to defend our API from malicious users and poor software regardless of how they approach it. A great lock on the front door isn’t sufficient if we leave the windows open.

Unified approach

In practice, clearly no security option is entirely failsafe, and each will come with an element of risk management. However, to create the most sophisticated solution for high security use cases, we recommend an API Gateway using OAuth.

The complementary technologies combine to create a powerful API access management solution that can limit particular OAuth scopes to specific devices, a specific network or group membership. More importantly, a security team can manage policies like this outside the API Gateway, while centrally logging access requests, grants and policy changes. Numerous data breaches have been caught by observant network security teams so the more we can capture this data centrally, the better protected we are.

Better solutions can help bring APIs out of the realm of ‘shadow IT’, and back to known, trusted systems and patterns. But remember: no solution is perfect, and today’s trusted partner may become tomorrow’s compromised system.

We need the flexibility to adjust, respond, and protect our systems based on the full context of the user and their goals. Only then can we take full advantage of this ‘always on, always connected’ world in safe, secure ways