About OIDC

Gloo Mesh Gateway supports authentication via OpenID Connect (OIDC). OIDC is an identity layer on top of the OAuth 2.0 protocol. In OAuth 2.0 flows, authentication is performed by an external identity provider (IdP). For successful authentications, the IdP returns an access token that represents the user identity. However, the protocol does not define the contents and structure of the access token. This ambiguity greatly reduces the portability of OAuth 2.0 implementations.

The goal of OIDC is to address OAuth 2.0’s ambiguity by requiring IdPs to return a well-defined ID token. OIDC ID tokens follow the JSON Web Token (JWT) standard and contain specific fields. You can write your apps to expect and handle these fields. This standardization allows you to switch between IdPs or support multiple IdPs at the same time. You need minimal, if any, changes to your downstream services. OIDC also allows you to consistently apply security measures such as Kubernetes role-based access control (RBAC) based on the content of the ID tokens. This way, you can use the same user identity information for authentication to apps in your cluster.

Supported types of OAuth2

The Gloo Mesh Gateway external auth server supports two types of OAuth 2.0: authorization code and access token validation. The way that you set these up vary by the OIDC provider.

Authorization codes

Authorization codes are commonly used in scenarios where end users access a web application. For example, you might want to control access to your API products in a developer portal that users interact with through a frontend web app.

Before a request is forwarded to a protected API product, the Gloo external auth server intercepts and redirects the request to the OIDC provider that you configured for client authentication. The client then authenticates through the OIDC provider. If the client is successfully authenticated, the OIDC provider issues an authorization code and stores it as a query parameter in the response. The client is then redirected back to the Gloo external auth server. The external auth server then exchanges the authorization code for an identity (ID) and access token. Finally, Gloo stores and uses the access token to authenticate the client’s requests. This way, the access token is not exposed to the user’s browser and is more secure.

For programmatic access, the user can instead provide the access token from the OIDC as a header in the initial request.

For more information, refer to the following resources:

Access token validation

For programmatic access, you can set up external auth to use access token validation. In such case, the user gets the access token from the OIDC provider first. Then, the user provides the access token in requests to your API products. Gloo stores and uses the access token to authenticate the user’s requests.

For more information, refer to the following resources: