Azure API Management offers a robust set of features designed to streamline the management of API traffic. Among its capabilities, it includes rate limiting, quotas, and authorization controls. These features collectively serve to simplify building and managing APIs by offloading complex tasks.
Server-side web applications traditionally sit adjacent to API Management. Security is often achieved by using cookies which have some benefits over JWTs.
As we shift our web applications to the cloud, change their identity providers from traditional providers like domain joined Active Directory to modern IdPs, and need them to consume newer JWT protected APIs, we face a challenge in modernizing them.
OAuth Reverse Proxies enable a traditional cookie-secured web application to run in a cloud-native world with minimal changes. They provide Open ID Connect flows, manage JWTs that are forwarded to the web application, and maintain a sliding cookie experience with the web browser.
OIDC Reverse Proxies do the following:
Azure App Service and Container Apps both provide an implementation of an OIDC Reverse Proxy which is perfect for many customers. But some organizations have strict controls over traffic flow – classic security zone models, mandating that only authenticated traffic is allowed to continue to downstream services. This leaves us needing something that can provide this functionality running in the same network area as API Management.
Azure API Management is massively extensible because of its built-in policy engine. It allows us to build and apply custom functionality using a subset of the dotnet libraries. We provide a sample implementation of an OAuth Reverse Proxy on GitHub: https://github.com/Azure/api-management-policy-snippets/tree/master/examples/oauth-proxy, which you can use to introduce modern authentication and authorization to your legacy web application.
The flows are provided by a combination of policies and policy fragments that must be added to your Azure API Management service. Detailed documentation on the fragments and how to wire it up can be found here: https://github.com/Azure/api-management-policy-snippets/tree/master/examples/oauth-proxy.
The policies have been written with security in mind:
Both the cookie and token encryption key support 2 keys, allowing you to safely rotate keys as required without impacting existing sessions.
You can choose to use your own external cache for storing tokens or use the APIM built in cache.
We have tested the policy against Microsoft Entra and Auth0. We have extracted the logic that builds the initial IdP redirect and the logic that provides the URL for the token exchange into their own policy files to make it straightforward to change the IdP as required.
View the example in the GitHub repository.
So, try it out, and let us know what you think.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.