In my previous article [Overview of API Access Control and implementing API key access control with BIG-IP APM] , I explained the ‘API-Key based Access Control’ method and we could see how a user implements it easily and securely using BIG-IP APM. However, although the ‘API-Key’ method has its advantages, it also has some limitations when we use it in the enterprise-grade API access control implementation.
Problems of the API-Key Access Control
API Key compromise
Although some improved API-Key systems can set an expiration time for API keys, the expiration time for keys has to be set for a longer time such as weeks, months, or a year. This is because the issued key should be configured manually to API clients or API G/W or API endpoints. This manual process requires extra operational overhead, thus it is normally recommended to use a long expiration time for keys. However, a longer expiration time may bring security problems as well. Let’s say the issued key is stolen without recognition by the organization, then what happens? Since the key’s expiration time might be set to months or a year, the attacker who stole the key can access the corporate resources until the key reaches its expiration time, a year in the worst case.
3rd party integration
Since the API-key method doesn’t have any pre-defined flow or format of the key, it could be challenging to integrate the enterprise’s API system with 3rd party client applications. For example, if Google, AWS, Dropbox, and Open banking services were to provide all different API access control methods, application developers would need to create all different modules for their applications to integrate each service. This is not a scalable solution to integrating the organization’s APIs with other 3rd party applications.
An OAuth 2.0 standard protocol was introduced in 2012 to solve these challenges and was defined in RFC6549. It was designed to implement API access control and is one of the most widely adopted methods for API access control purposes. The common misunderstanding of an OAuth is that it is considered an ‘Authentication protocol’. But it’s not an authentication protocol. While OAuth can provide authentication capability with its well-known extension – ‘OIDC(OpenID Connect)’, OAuth itself can work without OIDC and it primarily solves the access delegation problem. If a user wants to delegate third-party application access to their Gmail profile, OAuth can solve this. Many experts explain an OAuth with an example of a hotel key card. Once the key card is issued to the user, the room doesn’t authenticate the user but rather the valid key card. An OAuth works like a hotel key card, thus it is not an authentication protocol.
In an OAuth implementation, a token performs the same role as a ‘key’ of the ‘API-Key method’. One of the biggest technical advantages of OAuth is to provide centralized token management, user authentication, and a privilege consent process. This centralized policy management can help an enterprise to expand their API network and organizations more easily integrate their APIs with external applications. An OAuth is a big topic and we can not cover all the details of it in this short article. However, there are some important terminologies and concepts to understand the overall OAuth flow.
OAuth standard introduces 4 different roles in a typical OAuth flow.
OAuth grant types
OAuth grant types define how an OAuth client can obtain a grant from a resource owner to access their resources on their behalf. An OAuth 2.0 defines 4 different grant types.
1) Authorization Code Grant
2) Implicit Grant
3) Resource Owner Password Credential Grant
4) Client Credential Grant
Support OAuth in F5 solutions
Since OAuth is a key protocol for the enterprise-grade API implementation, F5 solutions support OAuth widely as well.
F5 BIG-IP APM and NGINX Plus support various OAuth roles and grant types. Organizations can build their own secure OAuth framework using F5 solutions.
Integrating with partner solutions
Since OAuth is a standard protocol, one of its strong benefits is to be supported by different vendor solutions. While F5 provides all types of OAuth roles in our product portfolio, we also provide tight integrations with our partner’s platforms, this includes leading vendors of IDaaS solutions – Microsoft Azure AD, Okta, and Ping. F5 BIG-IP APM has built-in OAuth configuration sets for these vendors already, so customers easily can configure their BIG-IP APM device to work with these vendor’s solutions. That means a customer can deploy Microsoft Azure AD or Okta or Ping Identity as their OAuth Authorization Server, and they can configure the BIG-IP APM and NGINX Plus API Gateway as their OAuth Resource Server. Both BIG-IP APM and NGINX Plus can work with those IDaaS vendor’s solutions to build an enterprise-level of OAuth for an organization.
An OAuth is an essential component to implement API access control to protect the enterprise’s API endpoints. However, the OAuth standard includes different roles, grant types, and extensions. Because of its complexity, some organizations may have some difficulty adopting the technology. F5 solution can help an organization adopt OAuth more easily. For example, F5 supports different roles of OAuth with multiple solutions – BIG-IP APM and NGINX Plus API Gateway. A customer can build their own OAuth network using F5 solutions only or they also can configure our solutions to work with industry-leading IDaaS vendors such as Microsoft, Okta, and Ping Identity. With all the flexibility and powerful policy management capabilities of the F5 solution, an organization can implement and operate its OAuth systems more effectively.