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.
OAuth 2.0
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 roles
OAuth standard introduces 4 different roles in a typical OAuth flow.
- Resource Owner(RO): RO indicates the person who owns the resources. If a fintech app tries to access a user’s banking account, the user is the resource owner(RO).
- Resource Server(RS): RS is the place to host protected resources. In the above banking example, the server which hosts the banking API is the resource server and the banking API itself is the resource.
- OAuth Authorization Server: OAuth AS is the centralized system to manage and issue the access token to OAuth clients.
- OAuth Client Application: The OAuth client indicates the application which wants to access a resource on behalf of the resource owner. In the banking example, the fintech app is the OAuth client.
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
- The application(=client) obtains the ‘authorization code’ first from the authorization server and the client exchange the code for an access token. This allows the access token to be never exposed to the resource owner’s user-agent.
2) Implicit Grant
- Optimized for in-browser JS clients. Instead of an authorization code, an access token is issued immediately without client authentication.
3) Resource Owner Password Credential Grant
- Username and password are used instead of an authorization code to obtain an access token. Should only be used for highly trusted clients or when other types are not available. Username and password are only used to get an access token and are not stored.
4) Client Credential Grant
- The client supplies its own credentials to get an access token.
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.
Summary
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.
