Your Azure Ad OAuth plugin is working great except when it is sitting behind an Azure Application Proxy. The App Proxy establishes a secure tunnel within our private network and allows us to expose internal applications to the web securely. One of the features of the service is Azure AD pre-authentication - which is what it sounds like - as the user visits the exposed site then the proxy will attempt to authenticate them before sending any requests to your internal app.
The issue at hand is that the internal app thinks the request is coming from an internal space and so when it requests the auth code and then the access token, it supplies the wrong callback URL (ie, http://internal.domain.corp/) instead of the application proxy url (ie, https://internalapp-company.msappproxy.net).
The RequestCode method already provided a hook via PreAuthUrlFilter that I could use to dynamically switch the CallbackUrl depending on the origin of the user's request (App Proxy adds some request headers that can be used to identify).
This PR extends similar treatment via PreAuthUrlFilter to RequestAccessToken.
This could be a breaking change for some end users but it does allow for this plugin to work for both scenarios where an application is exposed internally on a corporate network as well as published externally via the Azure App Proxy and utilizes pre-authentication.
A non breaking change would be to implement another filter hook.
Your Azure Ad OAuth plugin is working great except when it is sitting behind an Azure Application Proxy. The App Proxy establishes a secure tunnel within our private network and allows us to expose internal applications to the web securely. One of the features of the service is Azure AD pre-authentication - which is what it sounds like - as the user visits the exposed site then the proxy will attempt to authenticate them before sending any requests to your internal app.
The issue at hand is that the internal app thinks the request is coming from an internal space and so when it requests the auth code and then the access token, it supplies the wrong callback URL (ie, http://internal.domain.corp/) instead of the application proxy url (ie, https://internalapp-company.msappproxy.net).
The
RequestCodemethod already provided a hook viaPreAuthUrlFilterthat I could use to dynamically switch theCallbackUrldepending on the origin of the user's request (App Proxy adds some request headers that can be used to identify).This PR extends similar treatment via
PreAuthUrlFiltertoRequestAccessToken.This could be a breaking change for some end users but it does allow for this plugin to work for both scenarios where an application is exposed internally on a corporate network as well as published externally via the Azure App Proxy and utilizes pre-authentication.
A non breaking change would be to implement another filter hook.