Centralizing and Standardizing OIDC at the API Gateway Level
Anyone with experience managing computer systems knows the importance of identity and access management (IAM). How can you keep your application secure and operational if you have no process for identifying users and determining who should have access? Authentication and authorization are crucial for enabling the security and resilience of distributed systems.
As information systems continue evolving at an exponential rate, so too does IAM. Today’s information systems are very different from yesterday’s, and their changes are reflected in new processes for IAM. In this blog post, we will discuss the evolution of IAM.
Let’s start off with the very traditional monolithic applications of yesterday. Some users would try accessing the monolith in this architecture, and one IAM mechanism would be built into the monolith’s backend code. Authentication and authorization are relatively straightforward in monolithic architectures, as there was only one entry point to secure and one protocol to manage.
With time, many organizations broke their monoliths into microservices. IAM became much more complex, as it had to be individually embedded into each and every microservice. Multiple teams would often use different protocols to do so, making authentication and authorization a pandemonium. One service might have the OIDC protocol built-in, another might use LDAP, and a third might use JSON web tokens or JWT. Coordination between different protocols is not always apparent.
Of course, these challenges compound as you add more and more services. Most companies have hundreds, if not thousands of microservices and APIs to expose, each with its own IAM protocol. IAM becomes part of the development pipeline when it is embedded into each service. This detracts developers from focusing on their primary mission — to build features and applications that enable the company to react quickly to market changes. Streamlining the development process is crucial for companies to remain competitive.
The API gateway model
The API gateway model provides companies with a centralized way to manage authentication, so that they can offload the complexity of IAM from developers to DevOps teams or security teams. It removes IAM from the development pipeline. Let’s discuss the architecture of this model.
First, what is an API gateway?
An API gateway is a single entry point into your microservices that routes your client API requests to microservices in the backend of your network. An API gateway functions very similarly to a reverse proxy for standard user-facing applications in that it routes incoming requests to the correct API in the backend. Compared to a reverse proxy, an API gateway is more geared towards APIs and microservices and also layers in additional capabilities. Your API gateway enhances security with functions for authentication and authorization, management with HTTP caching and rate limiting, and observability with metrics, tracing, and logging.
An API gateway lives in front of all services and allows DevOps teams to centralize authentication and authorization. This is far more efficient than microservice-based architectures that require authentication and authorization to be embedded in each service. The API Gateway handles not only the routing of requests to the correct service, applying business logic to each request.
There are many benefits to this approach. API gateways allow you to easily enforce IAM standards across numerous applications through a single component placed at the edge of a network stack. As you don’t have to manage them independently in each service, you can make sure standards are enforced uniformly across the organization. The process for maintaining and updating policies and protocols is greatly simplified. It becomes much easier to, for example, swap LDAP for OIDC or update a group-based authorization policy that governs how people can access services. Everything is managed centrally at the API gateway.
API gateways strengthen security. When you centralize the management of IAM, you reduce the likelihood of individual applications failing to enforce security rules. Instead of having many single points of failure, you have one place to enforce security. There are many benefits to having an API gateway, and it truly is the next evolution of IAM.
Controlling IAM at the API gateway level
More and more customers are working with OpenID Connect (OIDC), an open protocol for authentication developed by an independent group of security experts. It is the direction IAM is moving towards. OIDC allows clients to request and receive the verified identity and basic information of end-users requesting access to HTTPS-protected endpoints from an authorization server.
OIDC is an identity or authentication layer that is built on top of the OAuth framework. These two words are increasingly used interchangeably, but let’s break them down. Authentication focuses primarily on verifying the user’s identity. Authorization is about the permissions a particular user or application has. It describes what resources can be accessed by whom.
OIDC is more secure than simpler authentication methods like Basic Auth, because it centrally secures multiple applications at once and enables single sign-on. Centralized identity providers also give security and IAM teams greater visibility into their application’s security. You can manage your users from a single identity provider and then leverage the data across your entire application stack.
Using Traefik Enterprise as an API gateway
Traefik Enterprise allows you to utilize several different authentication middlewares that can secure access to your back-end services. One of those is the OIDC authentication middleware.
Configuring OIDC authentication middleware in a Traefik Enterprise instance is a straightforward process. First, you specify your OIDC provider as an authentication source in your static config, so you centrally reuse the identity provider across several applications. Then you reference the authentication source in one or more OIDC middleware. Again, the idea is that once it’s set up, you can reuse it across many application configurations without having to repeat yourself. By default, the middleware will handle user authentication, and you will be redirected to log into the OIDC provider.
You can also use middleware to handle certain claim-based authorizations, as the middleware has the ability to extract claim data from the ID token as part of the OIDC standard. This way, you can ensure users are only accessing what they’re supposed to.
This diagram breaks down all the handoffs involved in an OIDC authentication process. First, the user sends an authenticated request to Traefik Enterprise’s middleware, redirecting the request to the OIDC provider. The user can then log into the centralized identity provider. Several steps are in the middle, including a handful of exchanges for authorization codes and tokens. The enterprise middleware sets a client-side session cookie to handle the session state on the user’s side.
After going through the authentication flow, the user will check the session’s validity and forward it to the back-end application. If it is valid, you will get a response from the application.
Traefik Enterprise makes OIDC as easy as possible. It centralizes authentication and authorization at the API gateway level, so protocols can be standardized and maintained universally instead of individually. Developers can focus on what they do best — creating business value with new features and applications.
To learn more about how Traefik Enterprise can help you take advantage of an API gateway, request a demo! We’d be happy to walk you through the ways it can help your organization. Alternatively, sign up for a free, 30-day trial and try its OIDC middleware for yourself.
