Announcing OpenID Connect support in OCI API Gateway

We’re excited to announce that Oracle Cloud Infrastructure (OCI) API Gateway now supports OpenID Connect, enabling developers to protect both APIs and web applications with a common network policy enforcement point. OpenID Connect enables single sign-on for disparate applications by centralizing the user management with an identity provider such as OCI Identity and Access Management (IAM) with domains .

Some legacy applications don’t directly support OpenID Connect. As they move to the cloud, you can use API Gateway as the network access point to mediate the authentication with users, the identity provider, and the application. Developers can use this to modernize existing applications, modern applications can also benefit from this capability. Instead of requiring all applications to add the OpenID Connect flows directly, API Gateway can enforce access in a standardized manner on the network.

Overview of OpenID Connect

The OpenID Connect (OIDC) protocol is a simple identity layer on top of the OAuth 2.0 protocol. OpenID Connect enables different types of applications, such as browsers, mobile applications, and desktop clients, to support authentication and identity management in a secure, centralized, and standardized way. Apps based on the OpenID Connect protocol rely on identity providers to securely handle authentication processes and verify user identities.

OpenID Connect authentication flow

OpenID Connect provides many capabilities that we don’t cover in detail in this blog, but the authentication flow has the following high-level steps:

1. Unauthenticated client calls the OpenID Connect protected application.
2. The application responds with an HTTP 302 redirect to the identity provider. In the URL, it adds identifier parameters so the identity provider knows for which application the authentication request is being made.
3. The identity provider provides the login and consent screen to the user.
4. If the user successfully authenticates, is authorized to use the application, and in some cases provides consent, the identity provider redirects the client back to the application with a temporary token.
5. The application then uses the token to exchange for an access token for the user and maintains a token with the client for subsequent requests. The application must keep secure the client ID and secret that it uses to validate the token with the identity provider.

How API Gateway helps you implement OpenID Connect

Easy to enable single sign-on support for your web applications

When engineering wants to integrate web applications with modern identity providers, such as OCI IAM, Okta, Auth0 or something similar, they’re now faced with the challenge of modifying legacy application code and changing its UI to support OpenID connect. Instead of new custom development, you can place API Gateway between the application and clients to intercept the requests and handle the OpenID Connect authorization flow.

Ship a more secure mobile application

You can make mobile applications more dynamic with OpenID Connect. Instead of storing the identity provider information within the app itself, the app can act as a user-agent. This behavior acts similarly to a web-browser that handles the redirects that it receives from the API and identity provider, which becomes critical because a mobile application cannot store secrets.

If a change must be made to a mobile application, it undergoes an update process in the app store. So, if the identity provider or the client ID, changes, it takes time to get the changes rolled out to the users. If the API supports OpenID Connect, the identity information is stored server side, and the mobile application is simply handling the redirection. Existing APIs don't have to be recoded to support this flow. API Gateway can add OpenID Connect to existing APIs.

Application to application integration

The standard API authorization patterns, such as rejecting an unauthenticated request with an HTTP 401, is also supported in API Gateway.

Typical API authorization

In many system-to-system integrations and trusted applications, details about the authentication server might be embedded in the client. The information can include a client ID and secret used by the application to either obtain an access token for itself or redirect the user to the identity provider to authenticate and complete the authorization flow. Examples include a modern web application directly handling the authentication flow with the user. The web application itself runs in a secure environment and can maintain the security of its client ID and secret. The general flow using the following steps:

1. The third-party system requests access to the backend services through the gateway by presenting a token acquired from the identity provider.
2. The gateway validates the token with the identity provider to ensure that the third-party system has access to backend services.
3. If the third-party system is authorized, the gateway routes to the appropriate backend service and returns the fulfilled response to the third-party system.

Web browsers and mobile applications

Web browsers can’t store confidential information, such as the client ID and secret used to obtain the access token. The web application supports the OpenID Connect flow redirecting the web-browser to the identity provider which authenticates and authorizes the user.

1. The client application requests access to the backend services through API gateway.
2. The gateway directs the client to the identity provider, such as OCI IAM , Microsoft Active Directory, and Okta.
3. The client authenticates with the identity provider. If successfully authenticated, the client receives a token that provides authorization.
4. The identity provider redirects the client to the gateway with the access token.
5. The gateway validates the access token with the identity provider.
6. If the token validation is successful, the gateway routes to the appropriate backend service and returns the fulfilled response to the client.

Learn more

To learn more about API Management with Oracle Cloud Infrastructure, visit API Management . Have a look at Validating Tokens to Add Authentication and Authorization to API Deployments and Adding Logout as an API Gateway Back End . For details about the OpenID Connect specifications, see OpenID .

Originally appeared on the Oracle Cloud Infrastructure Blog .

Authors: Robert Wunderlich, Product Strategy Director and Shyam Suchak, Senior Product Manager