Photo by Devin Avery on Unsplash
APIs are key components in any digital transformation journey. They enable organizations to create new business models and connect with partners and customers, while also providing seamless digital experiences by linking systems and services together. In today’s API economy, all modern architecture concepts deeply rely on APIs.
Access delegation is the primary security requirement in an API ecosystem, where someone else will access an API on your behalf and you need to delegate the corresponding access rights to the application or service. Providing end-users credentials or the usage of an API key is not a recommended approach anymore. OAuth 2.0 has become the norm for access delegation. When using OAuth 2.0, the access token is shared with a third party with limited access privileges and an expiry time. Along with OAuth 2.0, OIDC emerged as the authentication layer in API management platforms.
By nature, when the digital industry moves, hackers follow. So, with APIs becoming industry norms, hackers have sought out new ways to breach API ecosystems. The nature and sheer amount of data exposed, coupled with the exponentially high usage of APIs, increase the attack surface and the damage. Exposing sensitive data—e.g., personally identifiable information (PII)—cost companies millions of dollars in reparations and result in PR nightmares. For example, Facebook was fined £500,000 by the UK's data protection watchdog for its role in the Cambridge Analytica data scandal. And, two security breaches, which exposed the personal information of more than 1 billion users, cost Yahoo $350 million.
In a typical API management platform, the key manager component or authorization server mainly focuses on access delegation or securely managing access tokens. However, API security goes beyond simple authorization capabilities; refer to the Open Web Application Security Project’s (OWASP) recent API Security Top 10 for more details on this. This is why we need Identity and access management (IAM) solutions in API platforms to fill this security gap. IAM solution not only strengthens security but also brings additional capabilities to enhance digital transformation efforts. The following are IAM capabilities that are essential in your API management platform.
- Extended Access Delegation Capabilities
- End-User Identity Management
- Strong and Adaptive Authentication
- Cross Protocol Single Sign-On / Sign Out
- Identity Federation and Social Login
- Enforce Authorization
- Privacy Management
Extended Access Delegation Capabilities
The OAuth 2.0 core specification defines five main grant types: authorization code, implicit, password, client credential, and refresh grant type; however, the OAuth 2.0 framework is extensible to support advanced access delegation use cases such as an SAML 2.0 bearer grant or a Kerberos OAuth2 grant. In an SAML 2.0 bearer grant, if you have already logged in to an application with SAML protocol, you can exchange the same SAML 2.0 token to an OAuth 2.0 access token without breaking the user experience prompting re-authentication. If you are in a Windows environment you can use the same Windows login and get an OAuth access token using a Kerberos token. If it is a basic API management platform, basic authorization grants cater to the access delegation needs. However, the API management component is a cornerstone of your application. It should support extended needs so integrating enterprise IAM solutions with the APIM platform will enable advanced access delegation support.
OAuth 2.0 only provides the access grant but user identities are not revealed. If identity information is required, OIDC, which is an identity layer built on top of OAuth 2.0, can be used. In an OIDC flow, an access token and a JWT token with the user information is provided. This will be a primary feature of any IAM solution.
End-User Identity Management
API management platforms can be used within the organization or beyond. In either case, these APIs will be consumed by people, devices, or things. Hence, managing digital identities becomes a primary concern in any API management platform. Solutions have to deal with different types of identities: it can be people or devices or people and devices can access the same system. The number of identities that access the system can vary from thousands to millions. These identities often reside in heterogeneous identity stores.
Furthermore, how users change forgotten passwords, how you define password strength, the mechanisms available for end-users to recover their credentials, and whether an administrator can access a user’s account (with consent) are some typical concerns any system must address when dealing with identities.
Identity management is complex, but IAM solutions can effectively manage these complexities. Identities can be in multiple identity stores in different forms, maybe a single identity is distributed across multiple identity stores. These are only a few of our many concerns that come with identity management. In the initial stage of an API platform, you may not come across all of these, but having the right IAM system from the inception can ensure sure your platform is ready for future challenges.
Strong and Adaptive Authentication
Within the context of API security, often, we focus heavily on access delegation or securely managing access tokens; this hinders the importance of end-user authentication. Even now, username and password-based authentication is the most commonly used authentication mechanism. While it may be convenient, it is also the least secure authentication mechanism.
Multi-factor authentication (MFA) emerged as an answer to this problem. It implements a layered defense and made it more difficult for an unauthorized person to access a target, such as a physical location, computing device, web service, network, or database. The MFA concept is based on the assumption that if one factor is compromised or broken, an attacker still has at least one more barrier to breach before successfully breaking into the target. Therefore, it’s more secure.
Authentication factors in MFA rely on two or more independent credentials of three categories.
- Knowledge factors — Things only the user knows, such as passwords
- Possession factors — Things only the user has, such as ATM cards
- Inherence factors — Things only the user is, such as a fingerprint
The level of security provided by MFA has made it the best way to authenticate in the modern world. Even if one of the factors is compromised by an attacker, it is highly unlikely that all the other factors can also become compromised.
Conversely, even though MFA provides high security, it hinders usability. A static authentication flow is not convenient for different sets of users. To counter, adaptive authentication brings in the ability to switch the authentication flow based on the context. This shouldn’t be misunderstood as a completely different mechanism that replaces MFA. Adaptive authentication orchestrates different authenticators based on the context during the user authentication process. The best part is that most times users won’t even know that the authentication process has changed. Adaptive authentication intelligently takes in various factors in the current authentication process context and provides the authentication flow to the user.
Cross Protocol Single Sign-On / Sign Out
At a glance, we can say that the primary focus of the API management platform is to securely manage APIs exposed in the system. But, in a complete digital transformation project, API integration is just a fraction and there are multiple applications that consumers want to access to perform a given business use case. Single sign-on (SSO) is the mechanism that ensures customers have a consistent login experience with common credentials across different digital properties
Few authorization servers may support OIDC-based single sign-on. Even though modern applications support OIDC-based federation, most applications widely use SAML (and there are applications that use Ws-Federation as well). In most digital transformations projects, we see most of these protocols are being used in applications; therefore, you have to pick an IAM solution that supports all of these federation protocols. The solution should especially support cross protocols single sign-on along with sign out.
If a platform contains legacy applications that use proprietary protocols for federation, then, your IAM solution should have the capability to extend its federation authentication support for these non-standardized protocols as well.
Identity Federation and Social Login
A sophisticated API management platform should attract developers to interact with it. And, a thriving developer community is a sign of success for a platform.One indicator to judge an APIM platform’s success is the developer community around it. Developers commonly use Git, and, almost all have at least one social account, such as Facebook, Twitter, and LinkedIn. Allowing developers to use their social accounts to log in to the platform will attract more developers.
Even if you use API management platforms internally, you may have different business (BU) units, where employees reside in BU-specific identity stores and want to access the API platform. In this particular scenario, we can use identity federation to let these internal users seamlessly access the new platform. Even when an organization expands, e.g., following acquisitions and mergers, we can simply use identity federation to simplify complex identity integration needs and onboard new users in a few minutes.
Authentication verifies the identity of a person or device with the authorization to see whether that verified identity can perform the given action or access the data. In other words, authorization ensures users or things can only access what they are authorized to access. To implement authorization in an API we need to consider two levels of authorization. First, we need to validate the authorization in the API entry point to see whether this user can execute the given action. Then, we need to verify whether the user can access the exposed data.
The OAuth 2.0 scope is the best choice to enforce resource-level authorization. This can either be validated in the backend service level or in the API gateway level, which is the recommended clean approach. If we look at a basic OAuth 2.0 request flow scope validation can be done in two main places. In the authentication request flow before granting the access, the scopes need to be validated and check if authenticated users are eligible to grant the requested scope or not. Then, when it comes to API invocation, there should be another validation to check whether the API is accessible with the given scope. In the initial authorization validation, if you are using an IAM solution over basic key management components, it is possible to use more fine-grained authorization using XACML or an open policy agent (OPA).
Then we need to validate the authorization in the API implementation level to prevent unauthorized access to sensitive data. Even though a user is capable of invoking a given API action, he or she may not access the sensitive data. This should be validated in the code level where we need to pass the user information. This is another use case of JWT tokens, where authenticated user information can be passed into downstream services with the JWT tokens.
When developing a public-facing API management platform, privacy and compliance capabilities are foundational and the platform should focus on protecting the individual. Privacy standards and best practices continue to evolve in terms of both formal regulations and consumer expectations. The API management platform must adhere to an increasing number of consumer protection laws and regulations. For example, the EU General Data Protection Regulation (GDPR), which came into effect in May 2018 in the EU, is top of mind for organizations based in the EU or those that collect and hold data on people in the region. The GDPR primarily focuses on the protection of personal data and individual rights by giving control of their personal data to individuals. The regulation has catalyzed many countries to come up with their own privacy regulations. Multi-national organizations must worry about privacy regulations of each and every country they do business with and use an IAM solution sophisticated enough to ensure adherence to international privacy and data retention regulations when they build their API management platform or digital transformation journey.
APIs are the main element in any digital transformation journey. This exponential increase in API adoption has made it a prime target for hackers. Hence it’s important to correctly implement API security correctly. API platforms differ from one to another, hence, API security infrastructure should be designed to cater to unique requirements in each API platform and its sensitivity.
In a growing API platform, consumers are the main asset, and identity management is foundational. API consumers require a seamless onboarding and login experience along with enhanced security. Trust and privacy is a key expectation from both regulatory authorities and consumers. Hence, as I discussed in this article, coupling your API management solution with an enterprise Identity and access management solution is a key requirement now more than ever.