OIDC and OAuth
Use OpenID Connect (OIDC) with the OAuth 2.0 protocol to have an external identity provider authenticate requests with an access token.This feature is available with a Gloo Gateway license only.
About OIDC
Gloo 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 identity providers 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 identity providers 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
Gloo Platform's external auth server supports two types of OAuth2: authorization code and access token validation. The way that you set these up vary by the OIDC provider.
Authorization codes
In a typical setup through your frontend developer portal, you can use authorization codes for external auth. 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:
- API reference docs for authorization code
- Example guides for storing sessions in cookies or Redis, setting a logout URL, or forwarding ID tokens
- Google example guide
- Keycloak example guide
- Okta example guide
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: