Azure API Management OAuth Reverse Proxy

Posted by

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

OAuth Reverse Proxy Policy

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.

  • They automatically flow on form submissions,
  • Browsers natively update them based on web responses,
  • They allow us to build sliding sessions limiting their validity to the user’s session time.
  • No complex code is needed for the client to refresh JWT tokens.

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

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:

  • Redirect unauthenticated users to an identity provider to sign in.
  • Receive codes and exchange them for ID and access tokens using the PKCE flow.
  • Issue sliding session cookies to the browser.
  • Forward IdP issued JWTs to web applications.
  • Refresh expired tokens.
  • Provide sign-out flows.


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 OAuth Proxy

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:, 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:


The policies have been written with security in mind:

  • Randomizing state, nonce’s and code-challenges using 2 concatenated GUIDs.
  • Using customer-provided encryption keys along with randomly generated initialization vectors for securing session cookies and tokens at rest.
  • Storing the initialization vectors in the cookies so no process can decrypt a user’s token outside the session.
  • Using separate keys to encrypt tokens and cookies.


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.

IdP Support

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.



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.