Secure Web Applications Using OCI API Gateway and OpenID Connect
Integrating legacy web applications with modern identity providers typically requires modifying legacy application code and changing the user interface. Instead of spending time and resources on new custom development, invest in an architecture that enables you to focus on the business logic instead of the authentication flow.
Some legacy applications don’t directly support OpenID Connect. As they move to the cloud, you can use Oracle Cloud Infrastructure (OCI) API Gateway as the network access point to mediate the authentication with users, the identity provider, and the application. Instead of requiring all applications to add the OpenID Connect flows directly, OCI API Gateway can enforce access in a standardized manner on the network. Developers can use OCI API Gateway to modernize legacy applications, while enhancing modern applications.
Architecture
OCI API Gateway is a serverless, fully-managed service in OCI that can be used to protect API endpoints and web applications. OCI API Gateway provides security functionalities such as rate limiting, authorization enforcement, dynamic routing, SSL enforcement, and many more. OCI API Gateway can be leveraged to secure legacy web applications that require OpenID authentication support. OCI API Gateway can act as a centralized security module for web applications hosted in OCI private subnets. OCI API Gateway is identity provider agnostic, and can be integrated with any supported OAuth 2.0 provider such as Okta, Google, Amazon, and Auth0 to name a few.
The OpenID Connect 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 leveraging the OpenID Connect protocol rely on identity providers to securely handle authentication processes and verify user identities. OpenID Connect enables single sign-on for disparate applications by centralizing the user management with an identity provider such as Oracle Cloud Infrastructure Identity and Access Management.
OCI API Gateway acts as the network access point to mediate the authentication with users, the identity provider, and the application. Placing OCI API Gateway between applications and clients enables OCI API Gateway to intercept the requests and handle the OpenID Connect authorization flow.
The following diagram illustrates this reference architecture.
secure-web-applications-oci-api-gateway-open-id-architecture.zip
The following diagram illustrates the authentication flow for initial authorization.
secure-web-applications-oci-api-gateway-open-id-data-flow.zip
- The client application requests access to the backend services through OCI API Gateway.
- OCI API Gateway directs the client to the identity provider.
- The client authenticates with the identity provider. If successfully authenticated, the client receives a token that provides authorization.
- The identity provider redirects the client to OCI API Gateway with the access token.
- OCI API Gateway validates the access token with the identity provider.
- If the token validation is successful, OCI API Gateway routes to the appropriate backend service and returns the fulfilled response to the client.
When a client is already authorized, the flow resembles the following diagram.
secure-web-applications-oci-api-gateway-open-id-data-flow-authorized.zip
- After obtaining a token, browsers cache tokens for subsequent requests to the same application.
- OCI API Gateway validates the token with the identity provider to ensure the client has access to backend services.
- If the client is authorized, OCI API Gateway routes to the appropriate backend service, and returns the fulfilled response to the client.
The architecture has the following components:
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Availability domains
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domains
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.
- Virtual cloud network (VCN) and subnets
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- API Gateway
Oracle API Gateway enables you to publish APIs with private endpoints that are accessible from within your network, and which you can expose to the public internet if required. The endpoints support API validation, request and response transformation, CORS, authentication and authorization, and request limiting.
- Identity and Access Management (IAM)
Oracle Cloud Infrastructure Identity and Access Management (IAM) is the access control plane for Oracle Cloud Infrastructure (OCI) and Oracle Cloud Applications. The IAM API and the user interface enable you to manage identity domains and the resources within the identity domain. Each OCI IAM identity domain represents a standalone identity and access management solution or a different user population.
- FastConnect
Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.
- OCI and Azure Interconnect
Oracle Cloud and Microsoft Azure Interconnect is Oracle’s first multicloud offering. It delivers a direct network connection between specific Azure and Oracle Cloud Infrastructure (OCI) data centers around the world. It enables Azure administrators and developers to connect their applications to applications and services running in OCI without creating dedicated links or sending their application traffic across the public internet.
Recommendations
- OCI API Gateway
You can leverage OCI API Gateway for exposing REST APIs and enabling single sign-on support for your web applications. OCI API Gateway can also be designated as a centralized security module for applications to offload the security implementation to OCI API Gateway. This minimizes costs associated with implementation, maintenance, and complexity.
Considerations
Consider the following when deploying this reference architecture.
- Cross-Site Request Forgery (CSRF) Protection
An attacker can mount a CSRF attack by exploiting the existence of a browser cookie to cause users to submit unintended commands to a web application, such as an OCI API Gateway. If the application determines the user has already been authenticated successfully because of the browser cookie's existence, the application executes the command with potentially damaging consequences.
When you define a validation policy of type
OAuth 2.0 introspection endpoint, and a validation failure policy of typeOAuth 2.0, you specify how OCI API Gateway could store a new JWT token obtained using the OpenID Connect authorization flow.Select
Use cookies for sessionif you want to store new JWT tokens in a session cookie. To prevent potential CSRF attacks, when OCI API Gateway stores the token in a session cookie, it also returns a CSRF token in anX-CSRF-TOKENresponse header. Subsequent requests to the OCI API Gateway (apart from GET requests) must include the CSRF token in anX-CSRF-TOKENrequest header, in addition to the JWT token in the session cookie. - Cross-Origin Resource Sharing (CORS)
Web applications and other REST APIs used in the application may need to support CORS, as the requests are redirected through OCI API Gateway from web browsers.