Security is never a one-size-fits-all situation — true security strength comes from applying multiple layers and systems working in tandem to deliver a more secure product. Multi-factor authentication, or MFA, is a vital element of this comprehensive security approach. It allows developers and providers to create a lattice of security systems that make it harder for bad actors to penetrate trusted systems.

But what does the “factor” in MFA mean, and how does it grant additional security? Below, we’ll look at why MFA is so critical to the modern security posture, reviewing common factors and methods to implement it. We’ll also review four API providers that offer multi-factor authentication flows within their APIs.

Understanding Multi-Factor Authentication (MFA)

Before we dive into the four multi-factor solutions in this piece, we should first define multi-factor and why it’s critical to a proper security posture. While most people are vaguely aware that multi-factor means multiple verification methods, it’s actually a bit more complex than that.

Multi-factor authentication refers specifically to using two or more factors that exist across two or more categories of authentication. These categories are broadly separated into “something you know,” “something you have,” and “something you are” — with a few additional classes that we’ll cover shortly.

When the factors used for authentication are spread between two or more categories, we refer to that solution as being “multi-factor.” A key note here is that using two factors from the same category is, by definition, not multi-factor — if both items used are something you know, such as a pin and a password, that is not multi-factor and is instead a single factor. Let’s dive deeper into these factor types.

The Three Common Authentication Factors

1. Something You Know

Firstly, “something you know” is something the user can provide based upon their knowledge. For instance, a password or an account pin is an example of something a user knows. The problem with this factor is that it assumes only the user knows of it. Attackers, by definition, are seeking to capture confidential information, so leaning your entire security posture on a single source that is a principal threat is dangerous.

2. Something You Have

The second category, “something you have”, refers to an item or device in your possession that provides another level of security. This is a stronger level of authentication because it’s not something that is easily stolen from the authenticating user. Something you have, like a one-time password generator, is almost impossible (though not entirely impossible) to steal remotely.

3. Something You Are

The third category is “something you are.” This is, in many ways, the most secure of these factors, as it’s not something that can be stolen or replicated. A great example of this type of factor is biometric authentication. Cell phone users may be familiar with fingerprint-based authentication, where a scan of your fingerprint is used to authenticate account access and actions.

Uncommon Factors

Additional authentication factor classifications do exist. While they can be helpful to monitor for suspicious behavior, they are generally not considered reliable enough to stand as legitimate factors in MFA.

One uncommon factor that is starting to become wider utilized is “somewhere you are.” This factor is dependent on your physical location and is largely behavioral. IP whitelisting, location whitelisting, and other geographically-limiting authentication systems can ensure that only users from a recognized location can access a system. While this can be circumvented somewhat through the use of VPNs, heuristics and IP database usage can prevent this kind of traffic from being considered acceptable.

Another unique authentication method is “some way you behave.” This can include both the behavior you are trying to accomplish while authenticating — that is, you are trying to access a resource you typically access — or something you do to ensure access, such as gesture-based authentication. This type of factor authentication is useful, but only as an additional layer for security — e.g., if, and only if, other MFA factors have been secured, this should be used as an additional layer to ensure the MFA factors and the associated behavior that is being attempted are acceptable.

MFA and API Flows

Now that we’ve discussed multi-factor options in-depth let’s look at some example implementations that allow developers to add MFA flows to their APIs. Note that this is not a comprehensive list and that there are many different two-factor options available for a wide range of use cases and situations.

Auth0 MFA API

Auth0 is widely recognized as an identity platform for developers and programmers. Auth0 is a cloud solution explicitly designed around reducing the friction and complexity of authentication and authorization — accordingly, Auth0 has a strong MFA solution on offer as part of this greater collective product.

Auth0 provides built-in MFA enrollment and flows through a system they call Universal Login. Universal Login pushes authentication requests to a centralized authentication server. Because of this, there’s no need to add additional code or change the process on the API itself when adding additional functionality. Additionally, Auth0 provides an excellent GUI-driven authentication system, allowing authentication portals to be branded and unique to each service.

It should be noted that this MFA system is currently limited to SMS, voice, push (through the Auth0 Guardian App), email, and OTP, and as such, it is currently not configured to support Duo or WebAuthn. While this is not a huge negative, many enterprise organizations use Duo, and adopting Auth0 would either require a migration from this service or reconsideration of integration.

Curity Hypermedia Authentication API

Curity looks to solve a problem endemic to many authentication systems. A good portion of authentication in the modern space occurs in a browser environment. While many systems have proposed flows to solve this, the result is often still a half-designed workaround rather than a comprehensive fix. Curity offers a Hypermedia Authentication API to solve this specific problem.

The Curity API solution allows users to direct interaction with the Authorization Server. Since the Authorization Server still fundamentally controls the flows while providing the client-rich JSON responses, the client can interact in whatever way it can without restricting the types and modes of flows available. In essence, the documentation says it best — “let the Client handle the look and feel of the authentication process, and let the Authorization Server handle the authentication flow.”

There is a danger to this kind of authentication scheme, but Curity has adopted Proof-of-Possession tokens instead of Bearer Tokens within a client attestation mechanism, allowing for the prevention of interception and replay that comes with shifting responsibility systems such as this.

SAASPASS MFA API

SAASPASS MFA sells itself as an end-to-end identity management platform, but perhaps its greatest selling point is the relative ease with which it offers integration. SAASPASS carries a strong “plug and play” feel, allowing for immediate MFA additions with relatively light code additions for a wide variety of languages.

When code is required, SAASPAAS is relatively lightweight and digestible. For example, the following is an example implementation for a Java-based application that generates a simple application-scope token.

import org.springframework.web.client.RestTemplate;

class TokenGeneration {

    private static final String API_URL = "https://www.saaspass.com/sd/rest";

    public String getAppToken() {
        String url = "%s/applications/%s/tokens?password=%s";
        url = String.format(url, API_URL, APP_API_KEY, APP_PASSWORD);
        RestTemplate restTemplate = new RestTemplate();
        return restTemplate.getForObject(url, TokenResponse.class).token;
    }

    private class TokenResponse {
        private String token;
        public String getToken() { return token; }
    }

Notably, SAASPASS’s main focus seems to be on its app experience, allowing developers to register their company, generate keys, and allow for authentication through a mobile application. While some API developers may feel this is somewhat limiting, there is still the ability to add MFA directly through code. The addition of a mobile application can reduce the extra step of generating a token through Google Authenticator or other authenticator apps.

Microsoft Authentication Flows through MSAL

Microsoft handles an incredible amount of authentication through their systems, so it makes sense that they offer a comprehensive authentication framework for API developers to hook into. As part of the Microsoft Authentication Library, or MSAL, Microsoft provides a ton of great authentication flows for various applications. The ones most relevant to this piece are as follows:

• Authorization Code: Used to authenticate access from a device to protected resources, creating sign-in and API access flows for mobile and desktop apps. (Desktop, Mobile, and Web Apps)
• Device Code. Utilizes devices in an authentication flow, allowing constrained systems such as smart TV, Internet of Things modules, etc. to connect to a pre-set flow. (Desktop/Mobile Apps)
• Implicit Grant: Standard to most authentication systems, Microsoft also allows an implicit grant. This allows the user to sign in without having to connect to the back-end server credential exchange. (Single-Page Applications)
• On-Behalf-Of: Allows for delegated user identity, allowing an application or Web API to call additional applications, services, or APIs in a chain. (Web APIs)

It should go without saying that Microsoft has been around for a long time and has been instrumental in building out security tools for the web. Accordingly, it’s a relatively strong contender, especially for those running enterprise services or utilizing Azure for API functionality.

Conclusion

MFA systems are not a silver bullet. That being said, they do increase security significantly, providing greater trust in the security system for the developers and providers of the API as well as a higher level of confidence from the end-users in the system as a whole. If appropriately applied, MFA can be an excellent addition to the network of securing systems that protect your API.

What do you think? Are there other types of MFA factors that we missed? Let us know in the comments below!