Those poor Kardashians.
Although they already have more media exposure than any family could wish for, a few years ago they accidentally exposed their fans to potential cyber hacks. Right after the Kardashians launched four new websites, a tech savvy teenager discovered an unsecure API on the sites that made the names and emails of almost 900,000 subscribers accessible to hackers. Luckily the API was patched before any breach could occur.
Kim, Kourtney, and Khloe aren’t alone. McDonald’s, Salesforce, and T-Mobile have all suffered security incidents involving APIs in the past few years. Gartner Inc. expects this dangerous trend to worsen, predicting that by 2022, API abuses will be responsible for the majority of data breaches instigated by attackers within enterprise Web applications
What’s going on here? In part, the risk is simply growing along with increased API use. A survey of 250 IT security pros last year found the average company manages 363 different APIs. On top of that, 69 per cent of companies expose their APIs to the public as well as to their own partners.
Organizations are turning to APIs for very good reasons, of course! More than ever, APIs are a critical and strategic benefit to doing business, more important than ever in terms of enabling software solutions across the enterprise and with partners.
How can we get value out of APIs while minimizing their potential security risks? A growing number of enterprises – 63 per cent, according to the same survey we mentioned earlier – have turned to API gateways.
What is an Enterprise API Gateway?
An API or Service gateway is a security proxy between consumers of your enterprise services, and the backend services themselves.
By an API Gateway, I’m referring here to a platform that facilitates the sharing of services from inside the enterprise – like payments, product inventory catalogues and user account updates – to consumers of those services who could be deployed anywhere.
Why deploy an Enterprise API Gateway?
A gateway will ensure that the credentials of a consumer (like username, password or biometric information) are authenticated securely, allowing the consumer to change and manage credentials as needed to ensure security. The gateway will only allow access to services, or operations on that service, that have been explicitly authorized to the known consumer.
Should a breach occur, a request going through the gateway can be recorded, audited and blocked, giving a corporation confidence about what requests are made, when, by whom, and for what types of service or data.
The API Gateway can be seen as an additional security check, much like a firewall, but one that is checking information at the layer 7 protocol level. It reduces the security burden on a backend physical service, by helping to hide or protect against possible implementation flaws in the physical service.
Can’t we just rely on OAuth?
Most companies leverage OAuth2 protocols to ensure the owner of the data that the company has for an individual can be authorized for use by the individual themselves. OAuth is also a favourite among consumers; plugging their existing Facebook or Google credentials into third party apps is way easier than creating new user and password info for every single one, right?
What’s not as easy peasy, however, is implementing OAuth protocols securely on every service that an enterprise may choose to expose. Things like token introspection are difficult to standardize. If there’s a change in the identity product or software being used to implement OAuth token generation, it could trigger changes on many services all at once, making upgrades to the identity platform difficult.
Sadly, even OAuth isn’t infallible. Last year 50 million Facebook accounts were compromised when hackers exploited a weakness in the social network’s “View As” feature to breach users’ OAuth credentials. OAuth alone may not be enough.
Identity and the API Gateway
This is where the API Gateway really comes into its own. The token introspection and validation steps can be implemented at the gateway level, and even be customized to check things like customer attributes (account numbers, product numbers, etc.). This ensures that the service being invoked is indeed reading only customer data that belongs to the customer who authorized the use of the data by the software making the service call.
By ensuring consumers of a service only invoke it through the API Gateway, this adds a centralized layer of security beyond the functions described above.
So in addition to authenticating the consumer of the service (the application or software calling the service), there are other roles that the gateway can play with regards to identity. When it comes to customer, partner or employee identity, the API Gateway is an opportunity to add a lot of value to the service chain.
How to integrate identity and API Gateway?
The process of integrating an identity platform into an API Gateway can be complicated, and usually involves some level of software customization.
Solsys has performed these customizations and continues to grow this capability with our enterprise customers. If you’re interested in deploying, customizing or replacing a legacy API Gateway with a solution supporting these kind of identity and security operations, we would be pleased to share our experiences with you.