APIs are key components in any Digital Transformation journey. APIs are enabling organizations to create new business models, connect with partners and customers while providing a seamless experience by linking systems and services together. In this 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, where the digital industry moves hackers follow, when API becomes an industry norm it’s avoidable that hacker’s attention on API echo systems With the amount of data, the severity of the data exposed via APIs and higher usage of API increase the attack surface and the damage. Especially exposing sensitive data such as personally identifiable information (PII) costing companies millions of dollars in repairs and resulting in terrible PR.
In a typical API management platform key manager component or authorization server mainly focus on the access delegation or securely managing access tokens. But If we check recent OWASP API Security Top 10 it’s clear that API security goes beyond simple authorization capabilities. That’s why we need enterprise IAM solutions in API platforms to fill this security gap. Enterprise IAM not only strengthens the security but brings additional capabilities to enhance digital transformation journey. This article lists down these enterprise IAM capabilities which 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
OAuth 2.0 core specification defines five main grant types, namely authorization code, implicit, password, client credential and refresh grant type, but OAuth 2.0 framework is extensible to support advanced access delegation use cases such as SAML 2.0 bearer grant which exchange SAML 2.0 token to an OAuth 2.0 access token, Kerberos OAuth2 grant use kerberos token to authenticate the user. If its a basic API management platform basic authorization grants cater the access delegation needs. But the API management component is a cornerstone in your application which should support extended needs so integrating enterprise IAM solutions with the APIM platform will enable the advanced access delegation support.
OAuth 2.0 only provides the access grant but user identities are not revealed, in the case of identity information is required OIDC which is an identity layer built on top of OAuth 2.0 can be used. In OIDC flow, an access token and a JWT token with the user information is provided. This will be a primary feature in any IAM solution.
End User Identity Management
API management platforms will 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, devices or things or people and devices access the same system. The number of identities that access the system can vary from thousands to millions. These identities may reside in heterogeneous identity stores.
Furthermore, how users change their forgotten passwords, how you define password strengths, what mechanisms system provides their end user to recover their credentials. Can administrator impersonate an user account if a customer requests to do so. These are typical concerns any system wants to handle if they work with user identities
Identity management is complex, but IAM solutions can effectively manage these complexities. Identities can be in multiple identity stores in different forms, maybe single identity is distributed across multiple identity stores. These are some few concerns that come with identity management, in the initial stage of the API platform you may not come across these but when it starts to evolve you have to face, having an IAM system from the inception of your API management platform you can simply make sure your platform is ready for future challenges.
Strong and Adaptive Authentication
In the scope of api security it’s common that we pay extra attention to access delegation or how we securely manage access tokens, which I think hinders the importance of end user authentication. Even now username and password based authentication is the most commonly used authentication mechanism which is convenient and at the same time least secure authentication mechanism.
Multi-factor Authentication (MFA) emerged as an answer to this problem where it created 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 a database. 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 and therefore it’s more secure.
Authentication factors in MFA rely on two or more independent credentials of the 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. Given that one of the factors is compromised by an attacker, it is highly unlikely that all the other factors are also compromised.
Even though MFA’s provide high security it hinders the usability. Static set of authentication flow is not convenient for different sets of users. Adaptive authentication is 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 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 where consumers want to access to do 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 of the applications still widely use SAML and there are applications which use Ws-Federation as well. In most digital transformations projects we can see most of these protocols are being used in applications hence you have to pick an IAM solution that supports all of these federation protocols specially that solution should support cross protocols single sign on along with sign out.
Furthermore if this platform contains legacy applications which use proprietary protocols for federation then obviously, yours selected IAM solution should have the capability to extend its federation authentication support for these non standardized protocols as well.
Identity Federation and Social Login
Having a sophisticated API management platform with less developer attraction is not the organization objective. One indicator of the success of an APIM platform is the developer community around it. It’s common that developers use Git, and almost all the developers have at least one social account such as Facebook, Twitter, LinkedIn etc. Hence allowing developers to use their social accounts in login to the APIM platform will attract more developers.
Even if you use API management platforms internally you want internal users to access this platform, but you may have different business units in your organization, while employees of these BUs reside in BU specific identity stores. In this particular scenario we can use identity federation to let these internal users to seamlessly access the new platform. Further organization will grow with acquisition and mergers even in that case we can simply use Identity federation to do this complex identity integration in a simpler manner and let new users onboard to the APIM platform in a few minutes.
Authentication is the mechanism of verifying the identity of the person or the things, with the authorization it checks whether that verified identity is authorized to do the given action or access the given data. In other words authorization ensures users or things can only access what they are authorized to access. Implementing authorization in API we need to consider two levels of authorization, first need to validate the authorization in the API entry point whether this user can execute the given action then need to verify whether use can access the exposed data.
OAuth 2.0 scope comes as the best choice for enforcing resource level authorization. Either this can be validated in the back end service level or in the API gateway level where enforcing API gateway level would be the clean approach. In the typical OAuth 2.0 flow scope validation should be handled in two levels. At the time the client requests the scopes need to validate if authenticated users are eligible to grant the requested scope and then API invocation time if the API is accessible with the given scope. In the initial authorization validation if you are using an enterprise IAM solution its possible to use more fine grain authorization using XACML or 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 given API action he may not access the sensitive data. This should be validated in the code level where we need to pass the use information. This is another use case of JWT tokens, so 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 API management platform should focus on protecting the individual. Privacy standards and best practices continue to evolve in terms of both formal regulations and consumer expectations. 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 EU. 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 very important to implement API security correctly. API platforms differ from one to another, sensitivity of the data it shares is different hence, API security infrastructure should be designed to cater to unique requirements in each API platform and its sensitivity.
Further in a growing API platform consumers are the main assert hence identity management is foundational. API consumers required a seamless on boarding and login experience along with a confirmed security and trust and privacy is a key expectation from both regulatory authorities and consumers. Hence as I discussed throughout this article coupling your API management solution with an enterprise Identity and access management solution is a key requirement now more than ever.