This repository has been archived by the owner. It is now read-only.

OpenIdConnectProtocolInvalidNonceException: IDX10311 #542

Closed
andrew5277 opened this Issue Nov 14, 2014 · 38 comments

Comments

Projects
None yet
@andrew5277

am using openid connect authentication with ThinkTecture IdentityServer v3 as the authentication provide. In my MVC5 client, the setup for the authentication as follows. It works on the local machine, but get the following error after deployed on server. IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce is null. A nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'.

app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
Authority = ConfigurationManager.AppSettings["IdentityService"],
ClientId = ConfigurationManager.AppSettings["ClientId"],
Scope = ConfigurationManager.AppSettings["AuthorizationScope"],
RedirectUri = ConfigurationManager.AppSettings["RedirectUrl"],
//ResponseType = "code id_token token",

        SignInAsAuthenticationType = "Cookies",
        UseTokenLifetime = false,

        Notifications = new OpenIdConnectAuthenticationNotifications
        {             
            SecurityTokenValidated = async  n =>
            {
                var id = n.AuthenticationTicket.Identity;
                logger.Info("SecurityTokenValidated -" + nonce);

                //var username = id.FindFirst("username");
                var sub = id.FindFirst(Thinktecture.IdentityServer.Core.Constants.ClaimTypes.Subject);
                var roles = id.FindAll(Thinktecture.IdentityServer.Core.Constants.ClaimTypes.Role);
                var email = id.FindFirst(Thinktecture.IdentityServer.Core.Constants.ClaimTypes.Email);

                // create new identity and set name and role claim type
                var nid = new ClaimsIdentity(
                    id.AuthenticationType,
                    Thinktecture.IdentityServer.Core.Constants.ClaimTypes.Name,
                    Constants.ClaimTypes.Role);
                   nid.AddClaim(sub);
                   nid.AddClaims(roles);

                // keep the id_token for logout
                nid.AddClaim(new Claim("id_token", n.ProtocolMessage.IdToken));
                n.AuthenticationTicket = new AuthenticationTicket(
                    nid,
                    n.AuthenticationTicket.Properties);
            },
            RedirectToIdentityProvider = async n =>
            {
                if (n.ProtocolMessage.RequestType == OpenIdConnectRequestType.LogoutRequest)
                {
                    var idTokenHint = n.OwinContext.Authentication.User.FindFirst("id_token").Value;
                    n.ProtocolMessage.IdTokenHint = idTokenHint;
                }
            }
        }

error message:

Server Error in '/ContractDocumentSubmission' Application.

IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce is null. A nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: Microsoft.IdentityModel.Protocols.OpenIdConnectProtocolInvalidNonceException: IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce is null. A nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[OpenIdConnectProtocolInvalidNonceException: IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce is null. A nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'.]
Microsoft.IdentityModel.Protocols.OpenIdConnectProtocolValidator.ValidateNonce(JwtSecurityToken jwt, OpenIdConnectProtocolValidationContext validationContext) +811
Microsoft.IdentityModel.Protocols.OpenIdConnectProtocolValidator.Validate(JwtSecurityToken jwt, OpenIdConnectProtocolValidationContext validationContext) +394
Microsoft.Owin.Security.OpenIdConnect.d__1a.MoveNext() +6278
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +32
Microsoft.Owin.Security.OpenIdConnect.d__1a.MoveNext() +7987
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() +49
Microsoft.Owin.Security.Infrastructure.d__0.MoveNext() +1043
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Microsoft.Owin.Security.Infrastructure.d__0.MoveNext() +483
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.d__5.MoveNext() +291
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Microsoft.Owin.Security.Infrastructure.d__0.MoveNext() +1107
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Microsoft.AspNet.Identity.Owin.d__0.MoveNext() +662
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Microsoft.AspNet.Identity.Owin.d__0.MoveNext() +662
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.d__5.MoveNext() +291
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.d__2.MoveNext() +293
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +32
Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContext.EndFinalWork(IAsyncResult ar) +213
System.Web.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +434
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +288

@leastprivilege

This comment has been minimized.

Show comment
Hide comment
@leastprivilege

leastprivilege Nov 15, 2014

Member

What is different between the two environments? Can you provide network traces for both? and diffs?

Member

leastprivilege commented Nov 15, 2014

What is different between the two environments? Can you provide network traces for both? and diffs?

@andrew5277

This comment has been minimized.

Show comment
Hide comment
@andrew5277

andrew5277 Nov 16, 2014

local machine is a running on IIS express on windows 7. Server is running on IIS 8.5 on windows server 2012. I got the error message when I tired to log onto the server and viewed the page. When I tried to view the page on my local machine. it sometimes succeeded and sometimes felled into a loop after signed into the Identity Server because the aspnet cookied was not sent back to the page.
failed-trace1
failed-trace2
failed-trace3
failed-trace4
success-networktrace1
success-networktrace2
success-networktrace3

local machine is a running on IIS express on windows 7. Server is running on IIS 8.5 on windows server 2012. I got the error message when I tired to log onto the server and viewed the page. When I tried to view the page on my local machine. it sometimes succeeded and sometimes felled into a loop after signed into the Identity Server because the aspnet cookied was not sent back to the page.
failed-trace1
failed-trace2
failed-trace3
failed-trace4
success-networktrace1
success-networktrace2
success-networktrace3

@leastprivilege

This comment has been minimized.

Show comment
Hide comment
@leastprivilege

leastprivilege Nov 16, 2014

Member

I'd need a real network trace and the contents of the id_token for both cases. But I really think you might have a cookie or some other state keeping problem.

Member

leastprivilege commented Nov 16, 2014

I'd need a real network trace and the contents of the id_token for both cases. But I really think you might have a cookie or some other state keeping problem.

@andrew5277

This comment has been minimized.

Show comment
Hide comment
@andrew5277

andrew5277 Nov 17, 2014

How can I send you the trace.cap file? and What could be the possible causes of the cookie/state keeping problem. Thanks!

How can I send you the trace.cap file? and What could be the possible causes of the cookie/state keeping problem. Thanks!

@leastprivilege

This comment has been minimized.

Show comment
Hide comment
@leastprivilege

leastprivilege Nov 17, 2014

Member

Put it on dropbox/onedrive/whatever and paste the link here.

Member

leastprivilege commented Nov 17, 2014

Put it on dropbox/onedrive/whatever and paste the link here.

@andrew5277

This comment has been minimized.

Show comment
Hide comment
@andrew5277

andrew5277 Nov 17, 2014

https://www.dropbox.com/sh/h6sz4icdlbzmzzd/AAAMVbeBDeMA9EuanPaAf1lLa?dl=0

Thanks,
Andrew

On Mon, Nov 17, 2014 at 1:07 AM, Dominick Baier notifications@github.com
wrote:

Put it on dropbox/onedrive/whatever and paste the link here.


Reply to this email directly or view it on GitHub
thinktecture#542 (comment)
.

https://www.dropbox.com/sh/h6sz4icdlbzmzzd/AAAMVbeBDeMA9EuanPaAf1lLa?dl=0

Thanks,
Andrew

On Mon, Nov 17, 2014 at 1:07 AM, Dominick Baier notifications@github.com
wrote:

Put it on dropbox/onedrive/whatever and paste the link here.


Reply to this email directly or view it on GitHub
thinktecture#542 (comment)
.

@leastprivilege

This comment has been minimized.

Show comment
Hide comment
@leastprivilege

leastprivilege Nov 18, 2014

Member

I can't load your cap files with fiddler. How did you create them?

But I can verify that both id_tokens contain a nonce - you can check that yourself with http://jwt.io.

Maybe you are losing the nonce cookie from the openid connect middleware somehow.

Member

leastprivilege commented Nov 18, 2014

I can't load your cap files with fiddler. How did you create them?

But I can verify that both id_tokens contain a nonce - you can check that yourself with http://jwt.io.

Maybe you are losing the nonce cookie from the openid connect middleware somehow.

@andrew5277

This comment has been minimized.

Show comment
Hide comment
@andrew5277

andrew5277 Nov 18, 2014

After I switched the IIS Express to the local IIS, I am able to reproduce
the issue on my local machine. Here is the summary of the issue and steps
to reproduce.

  • started the Identity Server V3
  • running the client website from vs2013 on IIS Express
  • login page is prompted, signed in and redirected to the page successfully
  • logout from the identity server
  • close the current browser with IIS Express running, open an new browser(
    IE 11) and paste the page URL
    • the page was spinning and the sign in page was not shown , redirect
      back and forth to the Identity Server in a loop. If I started a fiddler at
      this time, I got the mismatched nonce error (see error_page.txt)
    • clear cookie, open a new browser and paste the page URL in the
      address. the login page was displayed, but after signed in, the page is
      spinning again. (identity user is authenticated at server, but not at
      client)

This happened on the server as well. By looking at the trace, the
difference seems that the authentication cookie (.AspNet.Cookies) does not
appear after signed in at the identity server.
I updated the trace files on the following link.
https://www.dropbox.com/sh/h6sz4icdlbzmzzd/AAAMVbeBDeMA9EuanPaAf1lLa?dl=0

Thanks,
Andrew

On Tue, Nov 18, 2014 at 12:07 AM, Dominick Baier notifications@github.com
wrote:

I can't load your cap files with fiddler. How did you create them?

But I can verify that both id_tokens contain a nonce - you can check that
yourself with http://jwt.io.

Maybe you are losing the nonce cookie from the openid connect middleware
somehow.


Reply to this email directly or view it on GitHub
thinktecture#542 (comment)
.

After I switched the IIS Express to the local IIS, I am able to reproduce
the issue on my local machine. Here is the summary of the issue and steps
to reproduce.

  • started the Identity Server V3
  • running the client website from vs2013 on IIS Express
  • login page is prompted, signed in and redirected to the page successfully
  • logout from the identity server
  • close the current browser with IIS Express running, open an new browser(
    IE 11) and paste the page URL
    • the page was spinning and the sign in page was not shown , redirect
      back and forth to the Identity Server in a loop. If I started a fiddler at
      this time, I got the mismatched nonce error (see error_page.txt)
    • clear cookie, open a new browser and paste the page URL in the
      address. the login page was displayed, but after signed in, the page is
      spinning again. (identity user is authenticated at server, but not at
      client)

This happened on the server as well. By looking at the trace, the
difference seems that the authentication cookie (.AspNet.Cookies) does not
appear after signed in at the identity server.
I updated the trace files on the following link.
https://www.dropbox.com/sh/h6sz4icdlbzmzzd/AAAMVbeBDeMA9EuanPaAf1lLa?dl=0

Thanks,
Andrew

On Tue, Nov 18, 2014 at 12:07 AM, Dominick Baier notifications@github.com
wrote:

I can't load your cap files with fiddler. How did you create them?

But I can verify that both id_tokens contain a nonce - you can check that
yourself with http://jwt.io.

Maybe you are losing the nonce cookie from the openid connect middleware
somehow.


Reply to this email directly or view it on GitHub
thinktecture#542 (comment)
.

@leastprivilege

This comment has been minimized.

Show comment
Hide comment
@leastprivilege

leastprivilege Nov 24, 2014

Member

Did you make progress on that?

Member

leastprivilege commented Nov 24, 2014

Did you make progress on that?

@andrew5277

This comment has been minimized.

Show comment
Hide comment
@andrew5277

andrew5277 Nov 24, 2014

No. I am working on a production release in December. I'll look at this
after that.

On Mon, Nov 24, 2014 at 3:02 PM, Dominick Baier notifications@github.com
wrote:

Did you make progress on that?


Reply to this email directly or view it on GitHub
thinktecture#542 (comment)
.

No. I am working on a production release in December. I'll look at this
after that.

On Mon, Nov 24, 2014 at 3:02 PM, Dominick Baier notifications@github.com
wrote:

Did you make progress on that?


Reply to this email directly or view it on GitHub
thinktecture#542 (comment)
.

@leastprivilege

This comment has been minimized.

Show comment
Hide comment
@leastprivilege

leastprivilege Dec 21, 2014

Member

I will close this - open a new issue when you encounter the problem again.

Member

leastprivilege commented Dec 21, 2014

I will close this - open a new issue when you encounter the problem again.

@johnkors

This comment has been minimized.

Show comment
Hide comment
@johnkors

johnkors Feb 3, 2015

Contributor

@andrew5277 Did you find out the root cause? Experiencing similar infinite redirect loops with MS OIDC MW.

Contributor

johnkors commented Feb 3, 2015

@andrew5277 Did you find out the root cause? Experiencing similar infinite redirect loops with MS OIDC MW.

@brockallen

This comment has been minimized.

Show comment
Hide comment
@brockallen

brockallen Feb 3, 2015

Member

Infinite redirects are due to the cookie not being issued (perhaps mismatch authentication type), the cookie not "sticking" at the client (http vs https), or failing authorization even though the user is logged in with a cookie (always returning 401, possibly because of the callback url in the middleware). Those are the 3 most common reasons for the loop.

Member

brockallen commented Feb 3, 2015

Infinite redirects are due to the cookie not being issued (perhaps mismatch authentication type), the cookie not "sticking" at the client (http vs https), or failing authorization even though the user is logged in with a cookie (always returning 401, possibly because of the callback url in the middleware). Those are the 3 most common reasons for the loop.

@andrew5277

This comment has been minimized.

Show comment
Hide comment
@andrew5277

andrew5277 Feb 3, 2015

I figured out it was caused by the authentication cookie not being issued,
but I didn't figure it out why. It's working on IIS express, but not IIS.

Here is the steps to reproduce the issue.

  • started the Identity Server V3
  • running the client website from vs2013 on IIS Express
  • login page is prompted, signed in and redirected to the page successfully
  • logout from the identity server
  • close the current browser with IIS Express running, open an new browser(
    IE 11) and paste the page URL
    • the page was spinning and the sign in page was not shown , redirect
      back and forth to the Identity Server in a loop. If I started a fiddler at
      this time, I got the mismatched nonce error (see error_page.txt)
    • clear cookie, open a new browser and paste the page URL in the
      address. the login page was displayed, but after signed in, the page is
      spinning again. (identity user is authenticated at server, but not at
      client)

On Tue, Feb 3, 2015 at 9:32 AM, Brock Allen notifications@github.com
wrote:

Infinite redirects are due to the cookie not being issued (perhaps
mismatch authentication type), the cookie not "sticking" at the client
(http vs https), or failing authorization even though the user is logged in
with a cookie (always returning 401, possibly because of the callback url
in the middleware). Those are the 3 most common reasons for the loop.


Reply to this email directly or view it on GitHub
IdentityServer#542 (comment)
.

I figured out it was caused by the authentication cookie not being issued,
but I didn't figure it out why. It's working on IIS express, but not IIS.

Here is the steps to reproduce the issue.

  • started the Identity Server V3
  • running the client website from vs2013 on IIS Express
  • login page is prompted, signed in and redirected to the page successfully
  • logout from the identity server
  • close the current browser with IIS Express running, open an new browser(
    IE 11) and paste the page URL
    • the page was spinning and the sign in page was not shown , redirect
      back and forth to the Identity Server in a loop. If I started a fiddler at
      this time, I got the mismatched nonce error (see error_page.txt)
    • clear cookie, open a new browser and paste the page URL in the
      address. the login page was displayed, but after signed in, the page is
      spinning again. (identity user is authenticated at server, but not at
      client)

On Tue, Feb 3, 2015 at 9:32 AM, Brock Allen notifications@github.com
wrote:

Infinite redirects are due to the cookie not being issued (perhaps
mismatch authentication type), the cookie not "sticking" at the client
(http vs https), or failing authorization even though the user is logged in
with a cookie (always returning 401, possibly because of the callback url
in the middleware). Those are the 3 most common reasons for the loop.


Reply to this email directly or view it on GitHub
IdentityServer#542 (comment)
.

@johnkors

This comment has been minimized.

Show comment
Hide comment
@johnkors

johnkors Feb 4, 2015

Contributor

@brockallen so idsrv does not do any validation when there is a cookie at idsrv already? I was thinking if idsrv actually did at least validation even when there is a cookie, this would stop the redirect loops and it would be easier to catch these kinds of errors on the client side (since idsrv spits out nice errors in the logs)

Contributor

johnkors commented Feb 4, 2015

@brockallen so idsrv does not do any validation when there is a cookie at idsrv already? I was thinking if idsrv actually did at least validation even when there is a cookie, this would stop the redirect loops and it would be easier to catch these kinds of errors on the client side (since idsrv spits out nice errors in the logs)

@johnkors

This comment has been minimized.

Show comment
Hide comment
@johnkors

johnkors Feb 4, 2015

Contributor

We put the MS OIDC MW on it's own path using app.Map, and all controllers using the [Authorize] attribute in it's own MVC area (here: web). Seems to have solved the issues.. Crossing fingers.

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    CookieName = "ourcookiename"
});

var options = new OpenIdConnectAuthenticationOptions
{                    
    RedirectUri = "http://domain/web/callback",
    SignInAsAuthenticationType = "Cookies"
};

app.Map("/web", a => a.UseOpenIdConnectAuthentication(options));
// previously we had:
// app.UseOpenIdConnectAuthentication(options)
    [RouteArea("web")]
    [Authorize]
    public class SomeController : Controller 
Contributor

johnkors commented Feb 4, 2015

We put the MS OIDC MW on it's own path using app.Map, and all controllers using the [Authorize] attribute in it's own MVC area (here: web). Seems to have solved the issues.. Crossing fingers.

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    CookieName = "ourcookiename"
});

var options = new OpenIdConnectAuthenticationOptions
{                    
    RedirectUri = "http://domain/web/callback",
    SignInAsAuthenticationType = "Cookies"
};

app.Map("/web", a => a.UseOpenIdConnectAuthentication(options));
// previously we had:
// app.UseOpenIdConnectAuthentication(options)
    [RouteArea("web")]
    [Authorize]
    public class SomeController : Controller 
@brockallen

This comment has been minimized.

Show comment
Hide comment
@brockallen

brockallen Feb 4, 2015

Member

@johnkors well, from IdSvr's perspective, the user just showed up with another authorization request from a valid client. Sure, it was less than 1 second ago from the last time, but that's general throttling. You could go insane trying to catch that on an* endpoint in any app.

Member

brockallen commented Feb 4, 2015

@johnkors well, from IdSvr's perspective, the user just showed up with another authorization request from a valid client. Sure, it was less than 1 second ago from the last time, but that's general throttling. You could go insane trying to catch that on an* endpoint in any app.

@johnkors

This comment has been minimized.

Show comment
Hide comment
@johnkors

johnkors Feb 4, 2015

Contributor

yeah, sure. I understand. Well, at least we got to test our throughput performance! ;)

Not sure why the solution i described worked though, seeing as we just moved it away from root ("/") and isolated the pipeline to OWIN using map. Katana heisenbug re cookie collection modification?

Contributor

johnkors commented Feb 4, 2015

yeah, sure. I understand. Well, at least we got to test our throughput performance! ;)

Not sure why the solution i described worked though, seeing as we just moved it away from root ("/") and isolated the pipeline to OWIN using map. Katana heisenbug re cookie collection modification?

@parkinsona

This comment has been minimized.

Show comment
Hide comment
@parkinsona

parkinsona Feb 16, 2015

@johnkors , how is that solution holding up for you?
I'd be curious to try it out. I'm assuming you could apply the RouteArea("web") as a global filter in your mvc app?

Our current solution to the looping issue, is to make sure you have the following in your global asax. There was another post related to this, which I can't remember the page for.

 void Session_Start(object sender, EventArgs e)
        {
            // place holder to solve endless loop issue
        }

@johnkors , how is that solution holding up for you?
I'd be curious to try it out. I'm assuming you could apply the RouteArea("web") as a global filter in your mvc app?

Our current solution to the looping issue, is to make sure you have the following in your global asax. There was another post related to this, which I can't remember the page for.

 void Session_Start(object sender, EventArgs e)
        {
            // place holder to solve endless loop issue
        }
@johnkors

This comment has been minimized.

Show comment
Hide comment
@johnkors

johnkors Feb 16, 2015

Contributor

The thing that ended up resolving our issues in the end was the Kentor CookieSaver mw. We experienced the redirects still (only in Azure) even with the area routing / app.Map.

Contributor

johnkors commented Feb 16, 2015

The thing that ended up resolving our issues in the end was the Kentor CookieSaver mw. We experienced the redirects still (only in Azure) even with the area routing / app.Map.

@parkinsona

This comment has been minimized.

Show comment
Hide comment
@parkinsona

parkinsona Feb 16, 2015

Ahhh yes.... I do remember seeing this Kentor CookieSaver a while back, but didn't pursue it because our workaround seemed pretty good.

Recently, I've noticed a few nonce exceptions, mainly when hitting the back button in the browser at various times. But rarely in my dev environment, I still get the endless loop issue. It's not been reported in other environments.

I'll give this Kentor CookieSaver a go.
On their github page, they mentioned a dummy session workaround? Is that what I listed above?

Ahhh yes.... I do remember seeing this Kentor CookieSaver a while back, but didn't pursue it because our workaround seemed pretty good.

Recently, I've noticed a few nonce exceptions, mainly when hitting the back button in the browser at various times. But rarely in my dev environment, I still get the endless loop issue. It's not been reported in other environments.

I'll give this Kentor CookieSaver a go.
On their github page, they mentioned a dummy session workaround? Is that what I listed above?

@parkinsona

This comment has been minimized.

Show comment
Hide comment
@parkinsona

parkinsona Feb 16, 2015

Unfortunately, I can still replicate my issue even with the Kentor CookieSaver.
I will open it as a different issue, because the steps to repicate are slightly different.

This is the new issue I raised: #931

Unfortunately, I can still replicate my issue even with the Kentor CookieSaver.
I will open it as a different issue, because the steps to repicate are slightly different.

This is the new issue I raised: #931

@bvarilone

This comment has been minimized.

Show comment
Hide comment
@bvarilone

bvarilone Mar 2, 2015

I believe the root cause of this issue is two-fold:

  1. The Owin authentication cookie does not get applied correctly due to a bug in Kantana
  2. The public and internal host names for the identity server do not match

In addition to utilizing Kentor.OwinCookieSaver (https://www.nuget.org/packages/Kentor.OwinCookieSaver) to address the first issue, try explicitly setting the Public Origin as part of the Identity Server V3 configuration (http://leastprivilege.com/2014/04/22/identityserver-v3-and-azure-websites-and-other-deployment-simplifications/) to address the second.

By taking these steps, I was able to successfully self-host Identity Server V3 in Azure.

I believe the root cause of this issue is two-fold:

  1. The Owin authentication cookie does not get applied correctly due to a bug in Kantana
  2. The public and internal host names for the identity server do not match

In addition to utilizing Kentor.OwinCookieSaver (https://www.nuget.org/packages/Kentor.OwinCookieSaver) to address the first issue, try explicitly setting the Public Origin as part of the Identity Server V3 configuration (http://leastprivilege.com/2014/04/22/identityserver-v3-and-azure-websites-and-other-deployment-simplifications/) to address the second.

By taking these steps, I was able to successfully self-host Identity Server V3 in Azure.

@mschulz531

This comment has been minimized.

Show comment
Hide comment
@mschulz531

mschulz531 Mar 2, 2015

@parkinsona This solution fixed the same problem in our environment as well:

Our current solution to the looping issue, is to make sure you have the following in your global asax. There was another post related to this, which I can't remember the page for.

void Session_Start(object sender, EventArgs e)
{
// place holder to solve endless loop issue
}

@parkinsona This solution fixed the same problem in our environment as well:

Our current solution to the looping issue, is to make sure you have the following in your global asax. There was another post related to this, which I can't remember the page for.

void Session_Start(object sender, EventArgs e)
{
// place holder to solve endless loop issue
}

@coreyperkins

This comment has been minimized.

Show comment
Hide comment
@coreyperkins

coreyperkins Apr 17, 2015

I have also encountered this issue. I've made it reproducible in my production environment repeatedly. If I type in my url as mydomain.com instead of www.mydomain.com it will happen after login with the third party provider each time (when I am redirected from google or microsoft back to my domain). The fiddler output should tell most of the story. When a user goes to mydomain.com they are redirected to www.mydomain.com. The nonce cookie appears to be available at mydomain.com but not when redirected to www.mydomain.com. I tried setting "CookieDomain" but it rendered the same results.

app.UseCookieAuthentication(new CookieAuthenticationOptions {
AuthenticationType = "Cookies",
CookieDomain = ".mydomain.com"
});

I also tried Kentor.OwinCookieSaver, it did not work.

I have made the Fiddler output public here: https://drive.google.com/file/d/0B1kNXPry-llgbFRSbGJFTER5Slk/view?usp=sharing

screen shot 2015-04-16 at 9 29 22 pm

Thanks ahead for any advice!

I have also encountered this issue. I've made it reproducible in my production environment repeatedly. If I type in my url as mydomain.com instead of www.mydomain.com it will happen after login with the third party provider each time (when I am redirected from google or microsoft back to my domain). The fiddler output should tell most of the story. When a user goes to mydomain.com they are redirected to www.mydomain.com. The nonce cookie appears to be available at mydomain.com but not when redirected to www.mydomain.com. I tried setting "CookieDomain" but it rendered the same results.

app.UseCookieAuthentication(new CookieAuthenticationOptions {
AuthenticationType = "Cookies",
CookieDomain = ".mydomain.com"
});

I also tried Kentor.OwinCookieSaver, it did not work.

I have made the Fiddler output public here: https://drive.google.com/file/d/0B1kNXPry-llgbFRSbGJFTER5Slk/view?usp=sharing

screen shot 2015-04-16 at 9 29 22 pm

Thanks ahead for any advice!

@leastprivilege

This comment has been minimized.

Show comment
Hide comment
@leastprivilege

leastprivilege Apr 17, 2015

Member

The cookie middleware is not used to set the nonce cookie. I guess you need to complain to Microsoft ;)

Member

leastprivilege commented Apr 17, 2015

The cookie middleware is not used to set the nonce cookie. I guess you need to complain to Microsoft ;)

@coreyperkins

This comment has been minimized.

Show comment
Hide comment
@coreyperkins

coreyperkins Apr 17, 2015

😄 Thanks for pushing me in the right direction!

😄 Thanks for pushing me in the right direction!

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 28, 2015

Do we have a work around for the Microsoft issues?

ghost commented Apr 28, 2015

Do we have a work around for the Microsoft issues?

@coreyperkins

This comment has been minimized.

Show comment
Hide comment
@coreyperkins

coreyperkins Apr 29, 2015

I tried the Kentor.OwinCookieSaver, but it didn't fix my issue.

I tried the Kentor.OwinCookieSaver, but it didn't fix my issue.

@ChrisVinall

This comment has been minimized.

Show comment
Hide comment
@ChrisVinall

ChrisVinall Apr 30, 2015

I've had a single instance of a user running into this exception and am having trouble following which of the above is relevant to me.

The setup is:

  • We host idsrv and its client ourselves in IIS
  • It works fine for most people, including when we log into the problem user's account locally
  • Our customer service rep remoted to the user's machine and was able to reproduce this problem.
  • The problem user is using Chrome in a work environment

The problem:

After going to the client website, and being redirected through the idsrv OIDC flow, IDX10311 was thrown on callback to the client. However, if the user then went back to the client website, she was logged in and could proceed through the app. While I couldn't be sure as we obviously had limited scope to debug, it didn't appear to involve an infinite loop.

Does anyone have any idea what could cause this problem?

I've had a single instance of a user running into this exception and am having trouble following which of the above is relevant to me.

The setup is:

  • We host idsrv and its client ourselves in IIS
  • It works fine for most people, including when we log into the problem user's account locally
  • Our customer service rep remoted to the user's machine and was able to reproduce this problem.
  • The problem user is using Chrome in a work environment

The problem:

After going to the client website, and being redirected through the idsrv OIDC flow, IDX10311 was thrown on callback to the client. However, if the user then went back to the client website, she was logged in and could proceed through the app. While I couldn't be sure as we obviously had limited scope to debug, it didn't appear to involve an infinite loop.

Does anyone have any idea what could cause this problem?

@nenadvicentic

This comment has been minimized.

Show comment
Hide comment
@nenadvicentic

nenadvicentic Aug 21, 2015

I produced same exception in the client ASP.NET website with 2 simple steps.

I first abandoned current Session and then called Authentication.Challenge() to redirect user to authorization server:

httpContext.Session.Abandon(); // Cause of the problem!

context.Authentication.Challenge(
    new AuthenticationProperties(),
    OpenIdConnectAuthenticationDefaults.AuthenticationType);

As a consequence of abandoning the session, ASP.NET pipeline does not output Set-Cookie: OpenIdConnect.nonce... in the redirect response, even though it was previously set by CookieManager. Browser never receives the cookie. After user gets redirected back from authorization server to the relying party, cookie is not there and nonce validation fails.

Core of the issue seems to be related with handling of Response.Headers in the Microsoft ASP.NET pipeline, which has some known issues.

IMPORTANT - To reproduce issue delete ASP.NET session cookie before hitting the page!

I produced same exception in the client ASP.NET website with 2 simple steps.

I first abandoned current Session and then called Authentication.Challenge() to redirect user to authorization server:

httpContext.Session.Abandon(); // Cause of the problem!

context.Authentication.Challenge(
    new AuthenticationProperties(),
    OpenIdConnectAuthenticationDefaults.AuthenticationType);

As a consequence of abandoning the session, ASP.NET pipeline does not output Set-Cookie: OpenIdConnect.nonce... in the redirect response, even though it was previously set by CookieManager. Browser never receives the cookie. After user gets redirected back from authorization server to the relying party, cookie is not there and nonce validation fails.

Core of the issue seems to be related with handling of Response.Headers in the Microsoft ASP.NET pipeline, which has some known issues.

IMPORTANT - To reproduce issue delete ASP.NET session cookie before hitting the page!

@loctanvo

This comment has been minimized.

Show comment
Hide comment
@loctanvo

loctanvo Aug 24, 2015

Contributor

@nenadvicentic That's very interesting. Could you update the Katana team with this information? Related issue: aspnet/Security#390

Contributor

loctanvo commented Aug 24, 2015

@nenadvicentic That's very interesting. Could you update the Katana team with this information? Related issue: aspnet/Security#390

@nenadvicentic

This comment has been minimized.

Show comment
Hide comment
@nenadvicentic

nenadvicentic Aug 25, 2015

@loctanvo No problem. I wrote description of the issue there too.

@loctanvo No problem. I wrote description of the issue there too.

@missxlian

This comment has been minimized.

Show comment
Hide comment
@missxlian

missxlian Feb 24, 2016

this fixed my problem
Notifications = new OpenIdConnectAuthenticationNotifications() { AuthenticationFailed = (context) => { if (context.Exception.Message.StartsWith("OICE_20004") || context.Exception.Message.Contains("IDX10311")) { context.SkipToNextMiddleware(); return Task.FromResult(0); } return Task.FromResult(0); } }

found from http://stackoverflow.com/questions/29502788/enabling-ssl-in-asp-net-mvc-5-app-results-in-openidconnectprotocolvalidator-issu

this fixed my problem
Notifications = new OpenIdConnectAuthenticationNotifications() { AuthenticationFailed = (context) => { if (context.Exception.Message.StartsWith("OICE_20004") || context.Exception.Message.Contains("IDX10311")) { context.SkipToNextMiddleware(); return Task.FromResult(0); } return Task.FromResult(0); } }

found from http://stackoverflow.com/questions/29502788/enabling-ssl-in-asp-net-mvc-5-app-results-in-openidconnectprotocolvalidator-issu

@jackjwilliams

This comment has been minimized.

Show comment
Hide comment
@jackjwilliams

jackjwilliams Jun 7, 2016

I'm experiencing this as well, and while @missxlian's solution works, it does not give me warm-n-fuzzy's. Is there a better proposed solution? I can reproduce simply by logging in, logging out then trying to log in again.

jackjwilliams commented Jun 7, 2016

I'm experiencing this as well, and while @missxlian's solution works, it does not give me warm-n-fuzzy's. Is there a better proposed solution? I can reproduce simply by logging in, logging out then trying to log in again.

@marconline

This comment has been minimized.

Show comment
Hide comment
@marconline

marconline Dec 7, 2016

Hello there, I think I found the root cause of this issue.

I'm summing up my discoveries:

  1. the problem is in the OpenIdConnect.nonce.OpenIdConnect cookie
  2. this cookie is set from the app (let's call this "ID Client") as soon as the OpenID Middleware init an authentication session
  3. the cookie should be sent back from the browser to the "ID Client" as soon as the authentication has been completed. My assumption is that this cookie is needed to have a double check from the ID client point of view (i.e. did I really started an OpenID Connect authorization flow?)
  4. a lot of confusion in me was caused by the "Nonce" term, used both in this cookie and in the OpenID Connect flow from the ID server.
  5. the exception, in my case, was caused by the missing cookie (not the nonce of the ID Server), simply because it wasn't sent by the browser back to the "ID client"

So the main root, in my case, was this: OpenIdConnect.nonce.OpenIdConnect cookie was not sent back to the ID Client by the browser. In some cases (i.e. Chrome, Firefox and Edge) cookie was sent correctly, while in others (IE11, Safari) it wasn't.

After a lot of research, I discovered that the problem was on the Cookie restriction policy, defined on the browser. In my case, the "ID client" is embedded in an <iframe>. This cause the "ID Client" to be seen as a "third-party client", because the user didn't navigate to that URL directly in the main window. Because this is a third-party, for some browsers, it's cookies have to be blocked.
Indeed the same effect may be obtained on Chrome, by setting "Block third-party cookies".

So, I have to conclude that:
a) if iframe is a must (as in my case, because "ID Clients" are apps that must run inside the graphic content of the our main platform app), I think the only solution is to intercept the error, and handle it with a page, asking the user to enable third party cookies.
b) if iframe is not a must, it should suffice opening the "ID Client" in a new window.

Hope this helps somebody, because I got crazy!

Marco

Hello there, I think I found the root cause of this issue.

I'm summing up my discoveries:

  1. the problem is in the OpenIdConnect.nonce.OpenIdConnect cookie
  2. this cookie is set from the app (let's call this "ID Client") as soon as the OpenID Middleware init an authentication session
  3. the cookie should be sent back from the browser to the "ID Client" as soon as the authentication has been completed. My assumption is that this cookie is needed to have a double check from the ID client point of view (i.e. did I really started an OpenID Connect authorization flow?)
  4. a lot of confusion in me was caused by the "Nonce" term, used both in this cookie and in the OpenID Connect flow from the ID server.
  5. the exception, in my case, was caused by the missing cookie (not the nonce of the ID Server), simply because it wasn't sent by the browser back to the "ID client"

So the main root, in my case, was this: OpenIdConnect.nonce.OpenIdConnect cookie was not sent back to the ID Client by the browser. In some cases (i.e. Chrome, Firefox and Edge) cookie was sent correctly, while in others (IE11, Safari) it wasn't.

After a lot of research, I discovered that the problem was on the Cookie restriction policy, defined on the browser. In my case, the "ID client" is embedded in an <iframe>. This cause the "ID Client" to be seen as a "third-party client", because the user didn't navigate to that URL directly in the main window. Because this is a third-party, for some browsers, it's cookies have to be blocked.
Indeed the same effect may be obtained on Chrome, by setting "Block third-party cookies".

So, I have to conclude that:
a) if iframe is a must (as in my case, because "ID Clients" are apps that must run inside the graphic content of the our main platform app), I think the only solution is to intercept the error, and handle it with a page, asking the user to enable third party cookies.
b) if iframe is not a must, it should suffice opening the "ID Client" in a new window.

Hope this helps somebody, because I got crazy!

Marco

@kleky

This comment has been minimized.

Show comment
Hide comment
@kleky

kleky May 9, 2017

I'm also experiencing this. missxlian's fix works, but I really don't know what it's covering up and if I should be concerned.

kleky commented May 9, 2017

I'm also experiencing this. missxlian's fix works, but I really don't know what it's covering up and if I should be concerned.

@marconline

This comment has been minimized.

Show comment
Hide comment
@marconline

marconline May 9, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.