You’ve got authentication and authorization figured out, right? The user logs in at the beginning of the session, and the framework essentially handles it from there.
While that may be true for monolithic applications, web application programming interfaces (APIs) are a different beast. API security isn’t the same as traditional application security.
We’re launching a series of posts to explore the differences between traditional application development and API and cloud-native development. We’ll also discuss how these fundamental differences affect the tools and techniques used to secure these applications.
First, let’s quickly define authentication and authorization. Authentication is the process of verifying a user’s identity. Essentially, it means making sure that a user is who they say they are.
You can implement authentication using one or more of the following methods:
- What a person knows (password or passphrase).
- What a person has (one-time token or physical device).
- What a person is (biometrics, fingerprint reader, facial recognition).
Authorization is ensuring that a logged-in user has the right to perform specific actions or view certain data. For example, I may have access to view my personal information through a web interface, but I shouldn’t see any other user’s data. I also shouldn’t have access to administrative functions.
Both authentication and authorization are necessary for an application to be secure. Getting into a party doesn’t automatically get you access to the VIP lounge.
You may see authentication abbreviated to authN and authorization abbreviated to authZ. These are shorthand often used in the industry. We use them from time to time, and they are interchangeable with the longer words.
Let’s dive into why authentication and authorization are different for APIs. There are three reasons.
Reason 1: APIs Are Distributed, Not Monolithic
How a web application appears to the end-user doesn’t reflect all of the pieces used to deliver its functionality. They experience a single interface that hides the complexity underneath. There could be hundreds of small microservices distributed in data centers worldwide doing the work necessary to display everything on the page or in your app.
Monoliths
Web applications were once monolithic. Essentially, that means they existed as one chunk of code running on a server. The server did most of the work, and one page or deliverable was passed to the browser at once.
The authentication and authorization mechanism in such a site is simple. After the user logs into the website, a single database holding user information verifies their identity. A session is created on the server, and all subsequent requests use the session to identify the user without another login required.
The rise of development frameworks made this process even easier for developers. Many frameworks handle session management out of the box, so developers don’t have to think much about it apart from wiring up the essential pieces.
Distributed
Web applications now consist of microservices distributed in cloud data centers. Each microservice is a self-contained server and data store bundled together but separate from the application’s other functions. A client application, the one the user interacts with, makes API calls to the services it requires to do its job.
Authentication and authorization look entirely different under this new distributed model. Since each microservice has a data store, a session created in one has no meaning to another. API calls would constantly break if the application depended on a single session ID created by the first server an application happened to call.
Distributed APIs require a new way of distributed authentication and authorization.
Reason 2: APIs Are Technology and Platform Agnostic
For many years, a company was a “Java shop” or a “.NET shop,” using only those technologies. Now, developers use many frameworks and languages across the enterprise.
Developers create microservices using frameworks and languages that make sense for the problem they’re solving. One microservice uses NodeJS with a MongoDB database. Another uses Scala and GraphQL. As long as each service adheres to the API it publishes for others to use, the implementation doesn’t matter.
These differences between languages and frameworks are another reason why authentication and authorization must change for APIs. Each language and framework has its own session management implementation, and every microservice has a different datastore.
An authentication and authorization technology for APIs must work for any programming language.
Reason 3: New Technologies and Development Techniques Lead To New Vulnerabilities
New technologies and development styles traverse a repeating cycle of security. First, a new technology appears on the scene that solves a problem. It catches fire in the industry as more people discover and start using it.
Unfortunately, when a new technology catches fire, security can become a secondary concern next to the problem it solves. Also, it’s not evident how to secure the technology because it’s unclear how attackers will break in or what vulnerabilities exist.
Malicious actors often have an initial advantage. They pick apart the technology and find new ways of breaking into applications and systems. The industry scrambles to catch up and seal the vulnerabilities discovered.
Traditional web applications have well-known weak spots. Over the years, many frameworks have built out-of-the-box protections for the most common of them. For example, frameworks such as Angular and .NET have built-in protection against Cross-Site Scripting and Cross-Site Request Forgery.
The concept of APIs has been around for many years. But the technologies used to enable the recent boom in microservices are relatively new.
These include:
- Containers
- Service meshes
- Container orchestration (i.e., Kubernetes)
- Service buses
- Serverless computing
- Cloud computing
As these technologies get used, new ways to get around their defenses emerge. Along with the technologies themselves come new challenges with the logistics of distributed, cloud-native architectures.
As a distributed architecture becomes more popular, the need for new authentication and authorization methods increases. These methods aren’t immune to the repeating cycle of security.
What Happens When Authentication and Authorization in APIs Are Broken?
Technologies used to create web applications have fundamentally changed. Authentication and authorization techniques have to change with them.
We’ve discussed three reasons why:
- APIs are distributed, not monolithic.
- APIs are technology and platform agnostic.
- New technologies and development techniques lead to new vulnerabilities.
But what happens when APIs have broken authentication and authorization? Our next post will cover the consequences of insufficient authentication and authorization practices in APIs.
Subscribe to our blog today to make sure you don’t miss any of the next installments.
About the Author
Justin Boyer is a former software engineer and application security specialist turned technology writer and a regular contributor to The Inside Trace.
