Many APIs have some core functions that are unique to them, but often these APIs are equipped with commonly used administrative functions. While this may have its pluses, API developers need the freedom to focus on the functionality of their APIs instead of worrying about the more common administrative aspects like authentication and authorization (AuthN/AuthZ).
When developers focus on what makes an API unique, many usually miss one of the most important aspects of API development — scaling the API. To scale the API appropriately, developers must look into offloading the administrative functions of multiple APIs in their apps. Scaling of the API at the design phase of the API is crucial to the success of API adoption in the long run.
AuthN/AuthZ are some of of the most challenging administrative API services to incorporate efficiently. Authentication allows API users to validate who they are, while authorization tells the API what those users have the rights to do or which resources the client can access. Developers can allow unauthenticated users to browse the site, but as soon as the API user needs to access confidential information or perform financial transactions, these organizations need to authenticate and then provide authorization to developers deserving of that level of access.
Many developers often create a separate authentication and authorization mechanism for each API. This process is far from ideal or being scalable. As shown in Figure 1 below, uncontrolled AuthN/AuthZ can spiral out of control quickly.
Figure 1: AuthN/AuthZ without an API Gateway. Source: Akamai Technologies.
As shown below in Figure 2, to sidestep this problem, instead of every API call having its own AuthN/AuthZ logic, developers use a scalable solution, which provides one source for all API AuthN/AuthZ calls needed by that application.
Figure 2: AuthN/AuthZ with an API Gateway. Source: Akamai Technologies.
One way to achieve this scalability is to decouple the API from its AuthN/AuthZ services by using an API Gateway to handle all of these authentication requests from a single source. This helps developers enhance the end-user experience by taking the burden of these extra requests off the server hosting the app. The success of this methodology is predicated on the geographic distribution of the users of the API. If all your users are concentrated in a local area, then a central AuthN/AuthZ proxy server can scale the API functionality.
However, most B2C APIs have a globally distributed client base, so how do you authenticate and authorize clients without forcing them to come to one or a few locations globally? Furthermore, how do you make sure your AuthN/AuthZ servers can handle the API traffic load during the busiest traffic times? The best solution to these questions is to make sure your developers understand where your users are, so they can move the gateway as close to them as possible.
AuthN/AuthZ needs to take place as close to the end user as possible to increase throughput, creating the best user experience at scale.
Now that you know you need a globally distributed API Gateway infrastructure to build a successful API, you and your API developers should focus on the next step. Beyond AuthN/AuthZ, developers may need to build other administrative functions into their API, such as selective access to data and services exposed by the API. This may require developers to build an access quota to help meet a business Service Level Agreement (SLA) established by the marketing and sales teams. Developers may consider using an API Gateway that allows the decoupling of API admin functionalities (for example, quota management) from the API core functionality. Otherwise, they may choose to roll their own code for such administrative functions.
In closing, a scalable API authentication strategy is the key to a successful API. Developers should consider how many APIs they need to manage and answer these questions:
- Have you considered what is needed from AuthN/AuthZ perspective as your user base grows?
- Are your APIs enabling their end users, their partners, or both? If they're enabling end users, are you using an API Gateway for AuthN/AuthZ of the users?
- How does API scalability affect your revenue generation and user retention?
- Have you considered API scalability to protect your users and revenue?
A focus on scalability early in the process will save a lot of time and prevent many headaches down the line. Once you've put an API Gateway is in place, you can delegate all future API administrative functions to it, so as to provide further scalability.