Request not allowed due to potential Open Redirection attack


I am trying to configure Azure AD SSO. My octopus server is behind a Caddy reverse proxy and I am able to access it externally.
When attempting to sign in with the “Sign in with Microsoft” option I receive the error “Request not allowed, due to potential Open Redirection attack” with IE. With Chrome or Firefox I only see an endless sign in animation.

I see a similar issue where this occurs when Octopus is behind ELB here although the issue has since been fixed. My configuration is already passing the required headers to the Octopus server as well.

Any idea on what I may be doing wrong?

Hi Dakota,

Thanks for getting in touch.

Could you please confirm which version of Octopus Server you are running?

Chrome and Firefox showing an endless sign-in animation doesn’t sound good. For Chrome, could you confirm if there are any errors in the browser’s console logs (or in the Octopus Server logs) when this occurs?

Could you also confirm the reply urls you have set in your Azure AD application?

We ran a quick test using Azure AD (with nginx as our reverse proxy) to help us confirm some things.

For example, when setting this up locally with nginx, we have an Octopus Server running on http://localhost:8065 and nginx configured to listen on http://localhost:81 with its proxy_pass set to http://localhost:8065.

To enable Azure AD, we run the configure command against our local instance:

Octopus.Server.exe configure --azureADIsEnabled=true --azureADIssuer=[our_issuer_guid] --azureADClientId=[our_client_guid]

The above command’s logs advised us to add the following reply url to our Azure AD app:

Add the following to the Authorized redirect URIs for your app: http://localhost:8065/api/users/authenticatedToken/AzureAD

This redirect URI that the log refers to is misleading when using a reverse proxy. It assumes you don’t have a reverse proxy or load balancer in front of it. So in our case, instead of using http://localhost:8065 as the log suggests, we added the public-facing URI of our reverse proxy (http://localhost:81) and that allowed us to then login with Azure AD using the reverse proxy address.

Could you confirm the configure command you are running looks similar to the above and that your Azure AD app’s reply urls include the public-facing/external reverse proxy address you have setup with Caddy?


Hello Mark,

I’m running Octopus 3.11.4.

Everything set in Caddy mirrors the configuration used in the nginx example and I am using the public Url for the reply Url, so no issues there.

It appears I had entered the Octopus.Server.exe configuration command incorrectly. Based on the instructions here I was under the impression that only the tenant Guid was required. After including the rest of the Url I am able to log into Octopus Deploy via SSO from Chrome and Firefox.

Strangely IE still displays the Open Redirection attack error and I cannot log in via SSO with it. Below are the errors and warning genreated in the IE 11 console when I load the page and attempt to sign-in via SSO.


Thanks you for your help so far and let me know if you need anything else from me.


Hi Dakota,

Ok that’s good news. We’ve also updated the documentation page with an example to hopefully make this more clear in the future. Thanks for pointing that out.

Thanks for the screenshot regarding the error. Re. IE 11, we believe this is the issue we fixed here, which was included in Octopus version 3.11.12. So if you upgrade, that problem should go away for you. Until then, you can workaround the issue by using Chrome or Firefox.

Hope this helps.