Infinite re-direct loop after AAD Authentication when redirect is specified

Question

If I specify a redirect URI in my OpenIdConnectAuthenticationOptions like so

app.UseOpenIdConnectAuthentication(
            new OpenIdConnectAuthenticationOptions
            {
                ClientId = clientId,
                Authority = Authority,
                PostLogoutRedirectUri = postLogoutRedirectUri,
                RedirectUri = redirectUri,

                Notifications = new OpenIdConnectAuthenticationNotifications()
                {
                    AuthenticationFailed = context =>
                    {
                        context.HandleResponse();
                        context.Response.Redirect("/Error?message=" + context.Exception.Message);
                        return Task.FromResult(0);
                    }
                }
            });

Then I get an infinite re-direct loop. This only happens though when i put it on and standalone IIS Server (our test server). If i remove all the Replay url's in AAD and leave it only setup for the test server, and remove the "RedirectUri = redirectUri," from the above my problem goes away.

I have a fiddler log here : https://drive.google.com/file/d/0B5Ap95E_wdyAa0RLLWloZ0dCaGM/view?usp=sharing

It appears that when request from AAD comes back to my app, before the token is grabbed and used, the Middle Ware is just bouncing it right back with a 302. Also what may be important, I have the [Authorize] attribute over the mvc controller that the routing and return uri directs to. If I remove it i do not get this issue.

[UPDATE] I tried moving the application to my localhost install of IIS rather than using iisexpress so that i could setup as a SubApplication like it is on my iis server. On my localhost it does the same infinite loop. I added in some telemetry custom events on an override of the [Authorize] attribute and have been able to discover that when page is re-directed back to the application after authentication httpContext.user.identity.IsAuthenticated = false. So somehow the OWIN middle ware is not setting this to true?

Thanks for any help!

I try to reproduce your problem but failed , could you provide more details to help us reproduce that , If you don't specify any value of RedirectUri parameter, the parameter will be omitted and Azure AD will pick the one registered at registration time . — Nan Yu, Jun 07 '17 at 06:50
@NanYu-MSFT Thanks for the comment. I forgot to add is that this application is setup as a sub app off of a main web site in iis, so "mainsite.com/thisApp". When it runs locally it runs as a standalone app, and i dont get the re-direct error. Do you think that could be part of the problem? Also, the first uri that was registered was the localhost version, then i manually added my test servers url path for a second reply url into AAD. Does that help at all? — Mike, Jun 07 '17 at 14:33
@NanYu-MSFT I was able to do a bit more testing and found out some more details(see above) Mainly though, the IsAuthenticated property is set to false after authentication when it comes back to the application but i dont understand why when it works perfectly on my local! — Mike, Jun 07 '17 at 19:18

Mike · Accepted Answer · 2018-05-04T12:59:02.233

4

I was able to find a solution to my problem. Originally i was specifying my reply url's to point to the root of the site. My rout config looks like this:

routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Welcome", action = "Index", id = UrlParameter.Optional }
        );

If I append "Welcome" to the end of my reply url it works. For some reason if i leave the reply url to the root of the site and have the default route picked up it just goes into an infinite loop.

I found out also that this only applies to a sub application of a site. I tried moving my application to be a standalone site in iis so rather than and I didnt have to add the controller name in the reply url.

Example:
Original reply url: mysite.mydomain.com/CustomApp

New Reply url: mysite.mydomain.com/CustomApp/Welcome

Hope someone else can find this useful!

UPDATE

I found out that the root of the problem was still caused from this mvc5 bug: katanaproject.codeplex.com/workitem/197. I thought it had been fixed but it has not, so i will continue to use the well known Kentor Owin Cookie Saver: github.com/Sustainsys/owin-cookie-saver

edited May 04 '18 at 12:59

answered Jun 07 '17 at 20:41

Mike

117
1
12

I found out that the root of the problem was still caused from this mvc5 bug: https://katanaproject.codeplex.com/workitem/197. I thought it had been fixed but it has not, so i will continue to use the well known Kentor Owin Cookie Saver: https://github.com/Sustainsys/owin-cookie-saver – Mike Oct 03 '17 at 18:43
1

Adding `Kentor.OwinCookieSaver` from NuGet and `app.UseKentorOwinCookieSaver();` before `app.UseCookieAuthentication(new CookieAuthenticationOptions());` worked a treat for me- thanks! – Lee Tickett Jan 03 '20 at 10:10
Hey, glad it helped! With the latest version of ASP.Net you no longer have to use the Kentor.OwinCookieSaver, they finally fixed the bug i think in one of the 4.6.x versions. – Mike Jan 16 '20 at 04:20
Which library do you think I need to update? I assume as I only set this up a few weeks ago I will be running the latest, but it is still exhibiting this bug. Also, do you have any ideas on https://stackoverflow.com/questions/59636308/azure-ad-authentication-breaking-http-post-actions-when-session-times-out/59636983#59636983 – Lee Tickett Jan 16 '20 at 08:25

score -1 · Answer 2 · edited May 03 '18 at 09:34

-1

Solved by using Never option for CookieSecureOption

app.UseCookieAuthentication(new CookieAuthenticationOptions()
            {
                CookieSecure = CookieSecureOption.Never
            })

edited May 03 '18 at 09:34

a1626

2,953
1
19
34

answered May 03 '18 at 08:49

Vatan Joshi

33
3

Infinite re-direct loop after AAD Authentication when redirect is specified

2 Answers2

Linked