Cookie Errors During Login

[npnelson]

I think your 01-Login sample is affected by this issue:

aspnet/Announcements#201

More information can be found here:

aspnet/Identity#915

I have been able to reproduce the issue using your 01-Login sample code. The ASP.NET team fixed their issue with a template fix, but the 01-Login sample is different enough that I can't figure out how to fix it.

[npnelson]

not that anybody is reading this, but after more research, I don't think it is related to the issue I referenced.

[ahouben]

I'd like to add to this thread, since I also think there is a problem with the 01-Login sample, the 02-Login-Embedded-Lock works fine with the same auth0 client configuration, all I did was changing the appsettings.json to the same values in both projects (tested on Chrome and Firefox).

Result:

• I get a 400 Bad Request on the call to https://<domain>/login/callback?state=<state>&code=<code> in the browser network trace, resulting in the following screen

• If I then press the browser back button to go back to the login page and login again with the same identity provider everything works fine and I'm redirect back into my application with an authenticated user. This behavior is deterministic.

Observations:

• 01-Login redirects to the login page at auth0 using a call to ChallengeResult which adds 2 url parameters compared to 02-Login-Embedded-Lock:
  • protocol=oauth2
  • response_mode=form_post
• 02-Login-Embedded-Lock uses the auth0 lock.js to display the login page inline

It seems state is lost somewhere for 01-Login.

[npnelson]

Wow! Thanks for posting that! I modified my app to work in the style of 02-Login-Embedded-Lock and it seems to work for me too (although it is too early for me to declare complete victory just yet). It would be nicer if 01-Login worked, but I'll take a working 02-Login-Embedded-Lock over what 01-Login is currently doing.

[npnelson]

Looks like I spoke too soon, I still get some cookie errors using Embedded Lock, not sure if they are less frequent or happen under different circumstances.

[npnelson]

hmmm..Sorry to keep blasting this issue. I realized I had my signout url misconfigured for my application in auth0. Once I fixed that, things seemed to improve.

[jerriep]

Sorry for not responding. This issue slipped past me :(

The problem appears to be that everytime the OIDC flow initiates, a nonce and correlation cookie gets stored. Problem is that when the OIDC flow does not complete successfully (because the browser's back button was clicked), then those cookies are not cleared.

So now if you do it a few times those cookies build up over time, and eventually things fail because the request becomes to big.

The issue you listed (aspnet/Announcements#201) is different. It relates to the external authentication cookie which is used by ASP.NET Identity. Our samples does not use ASP.NET Identity, or and external authentication cookie.

The nett effect is however the same, as these cookies are not cleared and build up over time.

I will look into this.

Let me know if I am not understanding the issue correctly

[jerriep]

Hey @npnelson and @ahouben

I have tested this in Chrome and Edge using the 01 - Login sample

I have gone through the login process about 50 times and did not get an error once.

Is there any way you have a reproducible sample which will fail every time give a certain set of circumstances?

[ahouben]

Hi @jerriep, I've set up a reproducible environment at https://greenlifftest.azurewebsites.net/ which deterministically fails for me using Chrome (version 53.0.2785.116 m) and Firefox (version 48.0.2 and 49.0) on Windows, but works perfectly with IE and Edge.

The deployment is an instance from the 01-Login sample solution with the only changes being (git diff -p):

diff --git a/01-Login/SampleMvcApp/appsettings.json b/01-Login/SampleMvcApp/appsettings.json
index f0f45c5..ae92d92 100644
--- a/01-Login/SampleMvcApp/appsettings.json
+++ b/01-Login/SampleMvcApp/appsettings.json
@@ -8,9 +8,9 @@
     }
   },
   "Auth0": {
-    "Domain": "{DOMAIN}",
-    "ClientId": "{CLIENT_ID}",
-    "ClientSecret": "{CLIENT_SECRET}",
-    "CallbackUrl": "http://localhost:5000/signin-auth0"
+    "Domain": "greenliff.eu.auth0.com",
+    "ClientId": "Xgvyyc<snip>",
+    "ClientSecret": "zQiA<snip>",
+    "CallbackUrl": "https://greenlifftest.azurewebsites.net/signin-auth0"
   }
 }

For you to test, the auth0 client set up is:

• Social identity provider: google (any gmail address should work, I'm using a gmail address for testing)
• Client Type: Single Page App
• Allowed Callback URLs contains https://greenlifftest.azurewebsites.net/signin-auth0
• Allowed Logout URLs contains https://greenlifftest.azurewebsites.net
• JWT Expiration set to 36000
• Use Auth0 instead of the IdP to do Single Sign On is off

[npnelson]

Also, @jerriep, I have had Auth0 support ticket #12340 open for a while now. Your support engineers have been able to reproduce this as well. I was able to reproduce it with 01-Login against Azure Active Directory, but I think your support team reproduced it with Google as a provider.

Thanks for looking into this!

[npnelson]

Another update: I've been told by support that they have a new branch of server side code that might help mitigate this issue, so if @jerriep is running on that new branch, that might be why he can't reproduce it.

I'm also told that as early as some time today, customers will be able to switch themselves to the new branch in the advanced dashboard (note I just checked and I don't see the feature deployed yet, but having the self service advanced dashboard switch deployed today wasn't a guarantee, just a best case scenario)

[jerriep]

Damn, I got it failing once but could not get it to fail again to try and
see what is happening. I will try again later during the day.

Please switch to the new branch when available, and let me know how that
goes

On Fri, Sep 23, 2016 at 5:20 AM, Nicholas P Nelson <notifications@github.com

wrote:

Another update: I've been told by support that they have a new branch of
server side code that might help mitigate this issue, so if @jerriep
https://github.com/jerriep is running on that new branch, that might be
why he can't reproduce it.

I'm also told that as early as some time today, customers will be able to
switch themselves to the new branch in the advanced dashboard (note I just
checked and I don't see the feature deployed yet, but having the self
service advanced dashboard switch deployed today wasn't a guarantee, just a
best case scenario)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA9bVDauEU46DM0iFXPJjwvZyZ2-Syl7ks5qsv9CgaJpZM4Jr9Ai
.

[npnelson]

I just switched the OAuth2 as a Service (preview) option on in the advanced settings (note to switch it on, you have to enable the Change Password v2 flow if that option is available before you can enable OAuth2 as a Service).

So far, so good, but it has only been an hour. I will know more once is has been in use a little longer

[ahouben]

The problem is related to browser cookie size limits.

tl;dr The auth0 backend at some point returns an auth0 cookie of size > 4096 which is silently ignored by Chrome and Firefox but still accepted by IE and Edge (due to different limitations for the allowed cookie size). This eventually results in the Oops!, something went wrong page.

Details:
The following workflow is run from an incognito chrome browser session, so there should be no previously existing state such as cookies:

1. Logging in the first time (works fine):

• Visit https://greenlifftest.azurewebsites.net/
• Click Login which redirects to the login page on <domain>.auth0.com
• The first call to the /authorize endpoint returns a auth0 cookie of size 312 bytes (247 bytes if the httpOnly and secure flags are removed) as shown in the chrome developer tools:

• If you then click the Google Social Identity Provider icon there's another call to the authorize endpoint which send the original auth0 cookie and returns a new auth0 cookie of size 3618 bytes (which is large but still fits into the cookie size limit of 4096 bytes, see https://tools.ietf.org/html/rfc6265#section-6.1) before redirecting to the social identity provider):

• eventually Google redirects back to the /callback endpoint of <domain>.auth0.com and the auth0 cookie size is reduced to 802 bytes:

• we are then successfully redirected back to our endpoint /signin-auth0 at https://greenlifftest.azurewebsites.net/ where the code is exchanged for a .AspNetCore.Cookies cookie and the previously set cookies .AspNetCore.Correlation.Auth0 and .AspNetCore.OpenIdConnect.Nonce are cleared:

• so far so good. Logout to see what happens when we login for the second time

2. Login for the second time (does not work and any login attempts thereafter do not work and behave the same):

• Click Login which redirects to the login page on <domain>.auth0.com, this time auth0 remembers us because of the auth0 cookie being sent along and the login screen looks slightly different ("Last time you signed in using..."). Our auth0 cookie size is now 952 bytes (instead of 247 bytes compared to the first login)
• If we now click the Google Identity Provider icon we get a 400 Bad Request from the /callback endpoint when google redirects back to auth0 due to a previous Set-Cookie attempt on the /authorize endpoint which is silently ignored by Chrome and Firefox (because the cookie size exceeds 4096 bytes) but still works on IE and Edge (cookie size limit here is 5117 bytes, according to http://browsercookielimits.squawky.net/):

Mitigation attempts:

• I tried to influence the cookie size on the auth0.com domain by changing the scope from "openid profile" to "openid email" with no luck, the auth0 cookie size was still too large. Is there anything I can do from my side to reduce the cookie size used on the auth0 domain ?
• I assume auth0 works fine with other oauth2 middleware (e.g. Java, Node), are the problems here related to .NET Core ? @jerriep You mentioned that these cookies are not cleared and build up over time. Does this apply here and could you elaborate on this ?
• Would you need to use cookie chunking/splitting and reassembly for the auth0 cookie whenever it exceeds 4096 bytes ?

Thanks in advance.

[ahouben]

@jerriep I see your login attempts on https://greenlifftest.azurewebsites.net/ in https://manage.auth0.com/#/logs. If you only got it to fail once this indicates that your browser allows for larger cookies than Chrome and Firefox (what does http://browsercookielimits.squawky.net/ say?)

[npnelson]

@ahouben First, thanks for the awesome post. Second, I just wanted to report that so far, so good on enabling the "OAuth2 as a Service (preview)" option in the advanced account settings on auth0. I can't speak for exactly what OAuth2 as a Service does, but I am pretty sure they took steps to reduce the size of the auth0 cookie (the preview may include other things too, I'm not sure).

My users have been using this for several hours now without a single cookie error or any other login problem. I'm not willing to declare victory just yet until I see it go for a few days, but the early results are very promising.

[ahouben]

@npnelson I just enabled "OAuth2 as a Service" and tried again. Unfortunately, the behavior is exactly the same as the aforementioned workflow using Google as the identity provider.

I can confirm that when using the Username-Password-Authentication login method the auth0 cookie size is only 2616 bytes, so the second and all other subsequent logins succeed.

So the auth0 cookie size seems to depend on the login provider.

[ahouben]

The Twitter provider works fine, but is close to the limits (auth0 cookie size 4088 bytes).

So, Google and Azure Active Directory (reported by @npnelson) seem to exceed the cookie limitations, maybe only in certain circumstances.

Cookie splitting and reassembly would solve it for all providers.

[npnelson]

Just to prevent a possible painful lesson for anyone who comes across this thread in the future - most mobile browsers can only store around 8K of cookies per site.

aspnet/Security#614 (comment)

It might not relevant for this case, because 8K is probably enough, but still something to keep an eye on, especially if you pull down "openid profile" for some providers that have lots of claims.

[nicosabena]

@ahouben Did you check if the OAuth as a Service (Preview) toggle stayed on? There is a subtle bug that causes the value not to change if you don't have the Password Flow v2 enabled.

[ahouben]

@nicosabena Once I enabled OAuth as a Service (Preview) it didn't go back. The Password Flow v2 was already enabled (probably when I created the auth0 account, I cannot remember changing or touching it):

[jerriep]

@ahouben @npnelson This issue seems not related to the ASP.NET Core integration or middleware, but rather between Auth0's server and the Identity Provider (Google in this case). I am going to ask that you please move this over to the support ticket already open, as it can be best managed by the product team on that side.

@nicosabena Can you please help and ensure that their ticket(s) get attention in Zendesk? I think you are already on top of it, but just making sure :)

If this issue is related to ASP.NET Core, then please feel free to re-open this issue.

[jerriep]

@ahouben Sorry, looking at your screenshots again, it seems the issue may be on the ASP.NET side for you. You ASP.NET Cookies seem quite large. Any idea why? Are you saving a lot of claims?

as for

these cookies are not cleared and build up over time
This is related to the correlation and nonce cookies. If you start an OIDC flow and then press Back in the browser, and then start a new OIDC flow, you will see new nonce and correlation cookies being created.

It was refered to as "Nonce overflow" and is discussed here:
http://katanaproject.codeplex.com/workitem/402
and aspnet/Security#179

[jerriep]

@ahouben Tested again. Sorry for the back-and-forth. The issue is on the Auth0 side, and not an ASP.NET problem. Do you have a ticket in Zendesk open by any chance?

If not could you head over to https://support.auth0.com/ and open a ticket with the steps and screenshots you outlined above (#3 (comment)) ?

Let me know what the ticket ID is and I can ask the product team to look into this. Thanks!

[ahouben]

@jerriep Thanks for following up. I've created ticket https://support.auth0.com/tickets/15036 in your support database and referenced this github issue and the ticket from @npnelson #12340 further up this thread (which I cannot view: Forbidden).

[jerriep]

@ahouben Whatever happened to this? Was your problem eventually resolved?

[jerriep]

I am closing this issue. If this is still a problem please re-open

[ahouben]

We mostly used the Database-Connection user store from auth0.com and therefore didn't run into this issue lately. I never verified whether the issue was resolved in the meantime.