At one point or another, your secure resources will be attacked. This is the unfortunate reality of the modern era, where the skills necessary to invasively crack open a system, network, or API are more commonplace than ever. Millions in resources and potential revenue can be lost in a matter of hours due to poor planning and implementation of a security protocol.

Private information, trade secrets, and even personal data can be exposed to the skilled network penetrator and used against you in ways that are as extreme as they are varied. This article aims to bolster your defenses by defining the four foundations of API security: Authentication, Authorization, Federation, and Delegation.

The Importance of Comprehension

One of the most common failures of understanding in the development of API security is the idea that security is a “one size fits all” solution. The idea that channels of security function in a singular manner with variations only in the final end-user experience is as wrong as it is dangerous; this concept places the operator in a position of fewer tools at their disposal than those trying to “break the system”, in turn exposing your data to an extreme level of unnecessary risk.

This issue is made worse by a common misunderstanding regarding the differences between Authorization, Authentication, Federation, and Delegation — perpetuating a gulf of misinformation and misapplication. This chasm has caused many security woes in the API space.

Given that these four terms are what the entire concept of API security rides on, it is imperative that you understand them, their uses, and the implications of their adoption. Lacking a basic understanding of security protocols, methodologies, and concepts can mean the difference between a prosperous, growth-oriented business and a stagnant, depreciating business.

Balancing Access & Permissions

Having an API that allows for full access to the entirety of your systems and resources is an absolute nightmare — it’s akin to being the lord of a castle, and leaving the doors to your vault wide open — it entices theft by its very nature, and unnecessarily opens your materials to the public space. As lord of your keep, why give marauders an avenue for attack?

What then is the proper response? Do we leave systems open for the betterment of functionality and assume users have positive intentions? Or do we follow a complete opposite route, closing down every bit of functionality, designing only proprietary systems?

The solution lies in combination of both approaches. Assume your foe is out to get you at all times — but don’t let this affect your need to do business. Constant vigilance allows you to design your API in an intelligent way, opening only that which needs to be opened, and making sure those openings don’t tie into vital systems that could be damaged. Functionally, this means assigning elements of authority to API consumers based on the minimal amount of access they need to do the functions they are required to do. By assigning different roles and levels of responsibilities to clients, we can create a tiered environment that keeps our data safe.

Understanding the implications of this system is of prime importance — specifically the differences between the types of rights and authorities within the system as a whole. In our definitions, we’ll hark back to our castle defense analogy. The brave and powerful knight Lancelot is trying to return to the Arthurian court after a long month of fighting bloodthirsty marauders — let’s see what defenses he will have to pass…

Authentication: Identity

“Tis I Lancelot cometh, bearing the password ‘Guinevere.'” Authentication is two-fold, establishing trust with identity and a secret code.

Authentication is a base security layer that deals specifically with the identity of the requesting party. Think of authentication as an agreement based on trust. When Lancelot reaches your drawbridge, he shouts his name along with a secret code to a guard stationed on the castle wall above. These two forms of identification will ensure that Lancelot is identified only as Lancelot, and that Lancelot is allowed to enter the castle.

In the real world, this level of security can take multiple forms. When a user chooses to request data or resources, they can face a number of protocols, log-in systems, and verification services. For instance, a user could log in using an authentication service that only requires a username and password. For greater levels of assurance, they may then be asked to provide a single-use token generated on a mobile device or keyfob.

Authorization: Access Level

Authorization is a completely separate level of security, though it’s often confused with authentication; while authentication verifies that the requester is who they say they are, authorization determines the access level they should be granted.

“Says here you’re Round Table status.” Authorization considers what access level the user has with the system. [Image: CC-BY-SA-3.0 via Wikimedia Commons]

Authorization is extremely important, but is often overlooked. It is very easy for API developers to assume that, because they need access to the API for their systems, setting the user default permissions to “SysOp” or equivalent full access is acceptable. This is a faulty line of thinking. While the developer inherently requires a higher level of access than the typical user, a consumer may only need a small portion of calls or functions at any one time. In that situation, leaving excess operations open makes the system more vulnerable to hacks and unauthorized access.

Federation: Reusing Credentials & Spreading Resources

Federated security is a multi-purpose system:

• for users, federated security systems allow for the use of a small set of credentials with multiple systems, services, applications, or websites.
• for administrators, federated security allows for the separation between the resources requested by the user and the systems used to authenticate and grant authority to the user.
• For organizations, it allows them to centrally manage the trust relationships they have with one another and ensure, cryptographically, that that trust is enforceable.

Same User Credentials Across Multiple Services

With federation, the user is granted the ability to use the same set of credentials across multiple services. By having the authentication take place in one single domain, other security realms that trust this primary domain can reuse the authentication and trust the authenticity of the identity established. This results in what is to what is called a federation.

Any system in this federation can accept the credentials of the authentication domain. The primary domain is what we call an Identity Provider (IdP) or Asserting Party (AP); the other security domains that trust the IdP to authenticate users are referred to as Relying Parties (RP) or Service Providers (SP). Authentication and identity data are passed between these parties using tokens. These Tokens are minted by a system called a Security Token Service (STS) or a Federation Service (OAuth Authorization Server and an OpenID Connect Provider are examples of an STS and a Federation Service, respectively.)

The end result is that a STS hands a token to the user after they first log into that authentication service. When the user then requests access to another domain, the domain registers that the user already has a token, and grants it access without requesting another log-in.

Introducing Realms

A federated backend stores resources across various systems, allowing users to access multiple services with the same credentials

The King knows that knights like Lancelot need to enter his castle; he also knows that his castle is situated in a very bad location, prone to raids. Because of this, the King has set up another castle some miles away in a more defensible position to house other precious resources. He does this to ensure security between the main castle and the more fortified castle that contains other valuable treasures. This adds an entirely separate layer of security, acting as a “buffer.” Federation allows for Single Sign-on (SSO) across these different “security domains” or “realms.”

In traditional systems that do not use Federation, the user would log into a server that is in a particular security domain/realm. This domain would include not only this authentication system but also the actual resources the user is attempting to access. While this works fine in some cases, if the authentication and authorization protocols were to be broken or violated, then the barrier between the resources and the user would also be broken. This could allow an attacker to take complete control of the domain.

When A Breach Occurs

With federated security, if a breach occurs in the Identity Provider, the Relying Parties can revoke the trust it had previously placed in that party — not all systems are compromised. Entry to all federated authentication requests made by any user to the resource server are refused. Imagine the King and his knights have retreated to the fortified castle after the main castle was overrun by raiders. They no longer allow entrance from people requesting access to the fortified castle for fear that they are actually raiders using stolen code words.

Delegation: The Signet of (Limited) Power

Delegation is another process by which access and rights can be given to authorized users while maintaining a relatively limited amount of access. Whereas federation works by giving the user a token to use on multiple domains, delegation works by authorizing a user to function partially as if they were another user.

Delegation can be compared to a signet, carrying the seal and permissions granted by an API provider

King Arthur, seeing the plight of Lancelot the Knight, has decided to make future access to his Kingdom easier. He creates a ring with his kingly seal set in pearl, and gives it to Lancelot. He then instructs his subordinates to follow Lancelot’s orders, given that they fall within his rights as a Knight and do not exceed the authority previously expressly given to him by the King. In this way, when Lancelot presents his signet, he is seen to be acting under the orders of the King, and does not need to further verify himself or be authenticated.

For web users, this is done on a site-by-site basis. For example, let’s assume the user is trying to log in to “https://mail.corporate.org”. Under the federation system, they would first have to login on a designated portal page to access any additional resources in the federation using their token. Under the delegation system, “https://mail.corporate.org” would look to see what rights they have been given and who they are acting on behalf of. As the user is coming from “https://profile.corporate.org” and has already logged in on that page using an authenticated account with elevated privelages, the mail server allows access.

Holistic Security vs. Singular Approach

Most important to all of these considerations is the way we treat the fundamental security system we are implementing. Far too often, developers fall into the trap of considering security to be one-sided. An average user might consider having three authentication devices to be a good security check; but if that authentication server were to ever go offline, you could have an infinite number of authentication-based security systems and your network would still be exposed. By thinking of security as a singular approach rather than a holistic one, you are placing your API and your system in far more danger than is necessary.

Consider security from the constraints of our story concerning Lancelot, and put yourselves in the rather silky, comfortable shoes of the noble and wise King Arthur. You know invaders are coming; in fact, you can see them crossing the mountain now, preparing to invade. Examine your security, and really contemplate your entire API Stronghold.

Would you consolidate all your jewels and gold in one fortress and defend with all men on a single wooden gate? — OR — would you rather spread your wealth across multiple fortresses each with an impassable moat, a manned wooden gate, a manned metal gate, and armed warriors waiting just beyond? Operationally, costs may be the same, but the security is drastically different. In the first scenario, the enemy would only have to destroy the wooden gate once to get into your castle, whereas in the second scenario, they would have to pass four separate and daunting obstacles to even get a peek at a single inner keep. A multi-layered stronghold is how you must consider security in the API space.

Application For APIs

When establishing a security system for your API, understanding Authentication, Authorization, Federation, and Delegation is vitally important. Deciding the access and specific circumstances behind sharing your resources will help establish a security shield to protect internal assets and solve many security issues before they arise.

For the modern system administrator, there is a wide range of tools and services available that make implementation of any of these types of security relatively pain-free. Services like OAuth and OpenID Connect can be integrated early in the development cycle of the API, and third-party authentication services can even be implemented after the API is deployed.

While all the above systems can work in tandem with one another, knowing when and where each are best applied makes for a better system on the whole, improving your security, usability, and longevity.