What options do APIs and microservices have when it comes to authentication and authorization? What is the role of identity in API security?

In our last LiveCast, we sought to discover best practices for handling identity within API security. We featured two illuminating lightning talks; one from David Garney of Tyk and another from Travis Spencer of Curity. Both will be holding workshops at the Platform Summit, so if you like what you read below, register for your spot today!

The Various Authentication Mechanisms

So, how do we authenticate users for our APIs? Embedded into third-party applications, APIs require a unique type of access control, and there are many options for microservices authentication and authorization.

The Benefits of Microservices

As we’ve seen before, microservices are lightweight, offering individualistic simplicity that monolith applications simply can’t provide. They are also flexible; services can be deployed to different hosts and with varying technical stacks. They work well with containerization, CI, and CD. Furthermore, since these applications are separated, it means the attack exposure is decreased, increasing security overall.

Though microservices are unique, they often work in tandem with one another, meaning we need them to act cohesively. One example is having a standard way of knowing who is consuming them and their access privileges.

So, how do we implement a standard authentication and authorization method across all microservices? In his presentation, Dave Garney of Tyke cites three specific ways to implement this control:

1. Internally within each microservice
2. Externally by using a gateway
3. Or using a combination of external and internal components

Internal Approach

In the 100% internal strategy, microservices handle both authentication and authorization. In this architecture, the user traverses through both. Thus, the service has fine-grained control, but it also means that the service is self-reliant, fitting with the microservices approach. Cons include extra development effort, and likely additional microservices must be being constructed to handle these functions.

Dave argues that by handling authentication and authorization separately for each microservice, we’re missing an opportunity to reduce code bloat. The larger the number of microservices involved, the more value in externalizing this approach.

External

With an external approach, a gateway handles both authentication and authorization. Thus, additional microservices do not need to be created. The pros are that by putting responsibility in the gateway, you can remove the burden from microservices to focus on your own needs. The cons could be less fine-grained control if the gateway can’t make decisions on information it doesn’t have access too. Dave also notes some potential vulnerabilities; relying completely on a gateway means you could attempt to circumnavigate it and access the source directly. Of course, there are ways to mitigate this.

Combination

In Dave’s combination approach, authentication takes place in the gateway, as the external approach, thus relieving the burden for each microservice to handle authentication. Authorization takes place in the microservice. Microservices thus become leaner as they don’t’ have to worry about authentication, yet they can still authorize based on the credentials provided. Cons could be a little bit more development effort.

Goldilocks Approach?

Dave recommends the external approach if possible, as allowing a gateway to handle both authorization and authentication brings time-saving qualities. He notes that, practically, most will use a Goldilocks approach; a middle ground between combination and external approaches.

Try to idenitfy complex authorization requirements and implement them in your microserivce.

Dave defines this way of thinking as Macro-authorization vs Micro-authorization. Macro-authorization as in the gateway authorizing access to all of your microservices and Micro-authorization as each microservice providing further authorization themselves. He recommends complex authorization mechanics catered to the unique scenarios at hand. Database access, for example, is best implemented as micro-authorization.

Dave recommends OpenID connect for authentication, and for the most part, stresses the importance of gateways for offloading functionality to the gateway:

What you should end up with is the right balance of off-loading as much authencitatoin and authroizaction effort to the gateway as possible, while retaining the ability to perform complex authorization at the microservice level.

Moving Forward with OAuth and OpenID Connect

Next, let’s dig into OAuth and OpenID Connect a bit more. Travis Spencer, CEO of Curity, is no stranger to strategies for identity control. He describes Curity as an advanced off-the-shelf OAuth server, fit for banking, retail, telecom, and many other use cases.

The 4 Actors of OAuth

Travis defines the basic foundations of OAuth with these four actors. This is what the literature and documentation concerning OAuth will often use. These 4 actors make up the flows that we discuss on the blog often.

• Client: The application; can be mobile apps, web apps, server applications, and more.
• Authorization Server (OAuth Server): Sometimes called identity provider, or in OpenID Connect it’s called the OP.
• Resource Server: These are the APIs themselves.
• Resource Owner: Typically a user, the one that controls the resource. Could also be an organization, but is often a user.

So how do these actors typically interact? Well, for more fine-grained comparison, we recommend you attend the Advanced OAuth workshop at the Platform Summit!

Registration Closed!