TLDR; deploy a reverse proxy with OAuth 2.0 and OpenID Connect capabilities in front of your existing API and web applications to secure those assets with the modern security and access control standards without having to touch them.
Organizations these days have an obvious choice when it comes to developing new applications and APIs and securing them: modern standards such as OAuth 2.0 and OpenID Connect provide an easy and standardized way to protect their assets in a future proof and secure manner. Things become more complicated when dealing with the existing landscape of applications and APIs. Embedding them in the same modernized security environment would make them benefit from the same advantages in the areas of standardization, cost reduction and security. Yet the existing applications are often hard to modify and extend with support for the modern security protocols so how to deal with that?
Enter reverse proxy: by leveraging the well-known, mature and widely deployed concept of a reverse proxy in front of the assets you want to protect you can make this happen. The reverse proxy doesn’t just allow you do put your sensitive existing applications/APIs behind it in an unmodified way, but also provides an architectural advantage: by externalizing access control from your application you can advance the implementation on either side independently. Thus it allows you to upgrade your access control capabilities without touching your application and you can upgrade your applications without risking changes in the access control layer.
There’s probably a lot of reverse proxy deployments in your organization today: you may be able to leverage the OAuth/OIDC capabilities that come with them to implement this scenario. When it comes to Apache and NINGX deployments, take a look at mod_auth_openidc and lua-resty-openidc respectively. These components can extend your existing (and unprotected or proprietary secured) APIs with OAuth 2.0 capabilities and your Web Applications with OpenID Connect capabilities. Things become even better when you can deploy and manage these functions as components in your microservices environment, see also my previous post about that.
Note that this “enhanced” reverse proxy (or: gateway) can work for API use cases – implementing the OAuth 2.0 Resource Server capability to verify access tokens – as well as for Web Access Management and SSO use cases – implementing the OpenID Connect Relying Party functionality to consume ID tokens. And one can deploy those capabilities alongside in a single instance possibly reusing that instance for many APIs and/or web applications.
Also note that this concept, as it adheres to standards, is independent of the Authorization Server (for API/OAuth 2.0 use case) or the OpenID Connect Provider (for Web SSO). The OAuth/OIDC Provider can be an on-premises deployment of a vendor specific product, or even a cloud-based service which allows you to lookup your on-premises applications to one of the various Identity-as-a-Service offerings through OAuth 2.0/OpenID Connect.
The microservice variant (e.g. a dockerized version of such an Apache/NINGX system) is IMO the most attractive way forward for new deployments: you can have your lean-and-man-Web-Access-Management-and-API-security-gateway-in-a-box today by leveraging mod_auth_openidc or lua-resty-openidc! Stay tuned for a follow-up post on how to deal with (fine-grained) access control in this reverse proxy deployment.