During Gartner’s recent IAM conference, I noticed an emerging conversation around the issues of API usage at the enterprise level. Enterprise adoption of APIs is viewed as an inevitable consequence of the ongoing digital transformation many IT professionals are managing.
API stands for Application Programming Interface and they help developers create applications that communicate easily with other applications and services. APIs are the backbone of any application ecosystem, which are a huge part of the trend towards digital transformation. All of those applications talking to one another are generating a huge amount of user data that enterprise companies need to be prepared to manage and secure.
A (Very) Brief History of API Access
Initially, users would authenticate to APIs (i.e., gain access to the functionality provided by integrated programs) using a username and password (the notorious password anti-pattern). As APIs became more widespread (and thus began to generate more information, increase in complexity, and demand greater security), devs introduced the concept of API keys. Better authentication protocols and flows soon followed with OAuth and Open ID Connect (OIDC). This allowed developers to grant access to certain functions in a given API through scopes and avoid having to share passwords.
With Great APIs Come Great Responsibility
As API security matures, it allows more companies to take advantage of APIs. With more companies, comes more customers, and more customers generate more data. The main concern with API usage now is securing the pipeline of information flowing between all of these programs.
Not every application will generate sensitive data. However, companies with incredibly sensitive customer information like those in healthcare and financial services can’t afford NOT to take advantages of the customer experience afforded by APIs. For example, the regulation PSD2 brought about in the Europen Union, forces European banks to open their systems to third parties – all of which will be accomplished using APIs.
This is where dynamic, contextual authorization (like ABAC) becomes essential.
An example on the other end of the spectrum, such as an application like Walgreen’s photo printing service, probably doesn’t require fine-grained level of access control.
Security Concerns Driving Fine-Grained Authorization
While system availability is probably the main concern when it comes to using APIs, there are security implications that certain industries should consider when developing products or deploying software internally that rely on APIs.
- Proper Authentication Ensuring the right individuals authenticate, can be held accountable, and can be billed for using the API. APIs cannot use a traditional user-application authentication (password-based) pattern. This is where OAuth 2.0 steps in to solve the password anti-pattern. They handle the authentication challenge elegantly and address coarse-grained access control. OAuth 2.0 is a great approach in B2C scenarios.
- Inter-Application Traffic Securing the traffic between client and service and not subject to eavesdropping. This is not a new challenge. Any client-server communication must be tamper-proof and confidential. This is part of the CIA triad: confidentiality and integrity of the message being exchanged. APIs make this an even more acute challenge. Traditional techniques using TLS handle this well-understood challenge.
- API Call Validation Preventing a call to an API from creating a security gap internally. This requires data validation and making sure the API calls cannot be abused for purposes other than the original intent.
ABAC should be in your API Security DNA.
As we’ve noted before, using ABAC to develop and implement APIs is the practical approach to securing your data.
ABAC focuses on delivering
- Functional access control, such as “Can Alice manage transactions?”.
- Transactional access control, “Can Alice approve transaction #234?”.
- Data access control, “Which transactions Alice can view, browse or delete?”.
ABAC takes a policy-based approach to authorization. This helps IT leaders improve and refine how they manage the access users have to sensitive data. Policies are easy to manage, maintain, and audit. It makes access control checks more transparent and easier to adapt when new business challenges or regulations come about. Other approaches require hard-coding controls in an API codebase. For instance OAuth 2.0 scopes rely on an API’s or application’s interpretation of what those entail leading to tight coupling of application logic with authorization.
Using ABAC enables a more loosely-coupled, easier-to-maintain architecture. It makes onboarding new APIs faster and more streamlined.
For more information on APIs and ABAC, visit APIs and Microservices.