The concept of zero-trust security is relatively simple. In essence, no entity or system should have trust by default. You should assume that any system you are talking to is not trustworthy until you establish otherwise. Within [Kong Konnect](https://konghq.com/kong-konnect)Kong Konnect, one mechanism to apply zero-trust is the [OpenID Connect API gateway plugin](https://docs.konghq.com/hub/kong-inc/openid-connect)OpenID Connect API gateway plugin.
In this post and the below recording from our Destination: Zero-Trust virtual event, I'll cover OpenID at a high level and some of its applications and use cases.
[OpenID Connect](https://openid.net/connect)OpenID Connect is a standard built on top of OAuth and JWT (JSON Web Token). Chances are, you’ve already used [OAuth and OpenID Connect](https://konghq.com/blog/engineering/openid-vs-oauth-what-is-the-difference)OAuth and OpenID Connect. For example, if you’ve used your Google account to log into a web application, logging in with your Google account authorizes a system to do something with resources that belong to you.
OpenID Connect takes this a step further and introduces authentication, which means now it’s almost like a passport. The system you interact with can determine who you are.
Additionally, the standard introduces some other functionality, such as session management. That way, if you’re accessing resources like an API more than once, you don’t need to apply [API gateway authentication](https://konghq.com/blog/learning-center/api-gateway-authentication)API gateway authentication and authorization every single time you use the API.
In the context of protecting APIs, you can tell the APIs who you are. You can also help those microservices and APIs figure out what you can or cannot do. In short, that's authentication and authorization.
There are other mechanisms APIs can use to establish if a client may use them. Digital certificates, for example, are common. You may have already heard of using API keys and all the caveats that come with it. OpenID Connect is a widely adopted standard that a lot of providers out there implement.
An identity provider centralizes all the access controls. That means you don’t have to define and manage access controls and the consumers repeatedly across the [API gateway](https://konghq.com/blog/learning-center/what-is-an-api-gateway)API gateway and all your systems. Instead, you rely on the IdP for this in a centralized manner. For example, if someone leaves the company, you can go to one place to remove their access from your systems.
Furthermore, you have an opportunity to reduce risks. I mentioned earlier using API keys, which can be a thing of the past. Instead, with OpenID Connect, you’ll typically have the access token issued to you. The access token is a short-lived credential used for some time and then is no longer useful. In the event of a leaked access token, that access token only has a certain lifetime, and once it’s over, it’s not something that other systems can exploit.
You can leverage OpenID Connect for many support flows, including:
I will begin by showing you the authorization code flow. From there, I'll switch to a bearer token, another mechanism that a consumer can use to identify themselves through the API gateway. And finally, I'll do something interesting: A header injection. That’s a bit of information useful to an upstream service when dealing with the consumer.
Before I jump into this, I want to warn you that OpenID Connect can be a little complex. If you go read any of the documentation or specifications, don’t be surprised if you see terms you don't recognize.
The above diagram shows a sample use case of the many flows that OpenID Connect can help you implement. In this diagram, the actors in the flow include:
The above is one flow. Let's take a look at another.
The authorization code flow would go something like this:
First, I'll show you the API gateway, configurations for an upstream service and how to protect it. If you’re not familiar with this user interface, don't worry; this is Kong's administrative user interface. Here, you can register all of your upstream services. Then you can decide how to expose them. And once you choose how to expose them, you can apply policies.
In this case, I’ll show you a policy specifically for working with an identity provider called [Keycloak](https://www.keycloak.org)Keycloak. Keycloak protects anyone who tries to access this path.
A typical consumer will go to the API gateway to request the path to a service. In this example, I'm demonstrating person-to-machine communication. The machine will authenticate and authorize the person. So I’ll go ahead and put my username and my password. Notice that I got redirected from the proxy. And once I logged in, I'm redirected back to the proxy. Also, notice there's this access token in the response. That is the identity provider telling the proxy the information it knows about this person.
It’s using the standard JWT. We can view it at [jwt.io](https://jwt.io)jwt.io. It’s a self-contained envelope, and you can see all the information that identifies the person who’s trying to consume the service. Notice, for example, that you can see the same email address that I put during the login page.
In this example, assume you already have an access token, and you want the API gateway to let you through without having to go to the IdP again. I'll use [Insomnia](https://insomnia.rest)Insomnia to test this use case.
For the last use case, assume that there is something in the information you know about the user that may be necessary for an upstream service to access. If you take a look over this access token, you will see that you have the scope (which can indicate applications to which this user has access). Remember, I talked about authentication and authorization. Here's an example of applying authorization. The API gateway has access to this information; what if you can extract it and give it to a service upstream?
I will modify the OpenID Connect API gateway plugin configuration to inject this information. It will make it visible here. I don't see it right now when I search for scope; it is empty. But once I modify the configuration so that I can let that upstream service get that information, it will be visible.
We will add the "Header Claims" and "Header Names." options in the configuration settings. Now we save and update my configuration.
If I try to re-access this API, I will now have a scope available for me that matches what the bearer token contained. That means whatever upstream service I was working with now has this information too.
There is a benefit here. You don’t have to rewrite or maintain the code over and over. And that makes it faster for the developers of the upstream services to get their work done.
Now that you're familiar with the high-level concepts, I recommend checking out this post for step-by-step installation steps: [How to Secure APIs and Services Using OpenID Connect](https://konghq.com/blog/how-to-secure-apis-and-services-using-openid-connect)How to Secure APIs and Services Using OpenID Connect.
Running Kong in front of your Solace Broker adds real benefits: Authentication & Access Control – protect your broker from unauthorized publishers. Validation & Transformation – enforce schemas, sanitize data, and map REST calls into event topics.
[](https://konghq.com/blog/engineering/smarter-event-driven-apis-kong-solace)
When it comes to digital identity, OpenID and OAuth are two peas in a pod, but they have their differences. OpenID connects you to relying parties using a single sign-on, while OAuth grants access tokens so you can give apps limited access. They bo
[](https://konghq.com/blog/engineering/openid-vs-oauth-what-is-the-difference)
A modern API gateway like Kong enables organizations to achieve some use cases much more easily than traditional gateways. The reason is older, traditional gateways try to provide as many features as possible into a heavyweight monolith, while mod
[](https://konghq.com/blog/engineering/how-to-secure-apis-and-services-using-openid-connect)
Traditional APIs are, in a word, predictable. You know what you're getting: Compute costs that don't surprise you Traffic patterns that behave themselves Clean, well-defined request and response cycles AI APIs, especially anything that runs on LLMs
[](https://konghq.com/blog/engineering/monetize-ai-apis)
The challenge: A disconnected world Consider the typical enterprise architecture in a relatively mature organization, an API management layer defines and deploys services to an API gateway, an Identity Provider (IDP) manages human user identities, a
[](https://konghq.com/blog/enterprise/api-management-and-identity)
APIs facilitate effortless communication and data exchange between applications and services. However, their inherent design, which codifies service capabilities within the API definition, makes them easily exploitable by malicious actors. API attac
[](https://konghq.com/blog/product-releases/content-inspection-injection-attack-protection)
In today's interconnected web ecosystem, modern applications frequently need to communicate across different domains, making Cross-Origin Resource Sharing (CORS) a fundamental concept for web developers to master. This comprehensive guide explores C
[](https://konghq.com/blog/learning-center/what-is-cors-cross-origin-resource-sharing)