I wanted to follow up @kevin.mcginley on this topic and what we were able to find after looking at the HAR files you sent over.
Initially you mentioned about receiving a status of 404 for
/user/ssodata. One of our Engineers @nicolas_sabena gave a terrific explanation on this that I am going to quote below:
/user/ssodata is no cause for concern. Read below for more details.
When a user already has a session in Auth0 and an application requests a new token, Auth0’s Lock used to present a “Last time you logged in as email@example.com” button in the hosted login page that would let you reuse the existing session easily (no need to enter credentials again).
New tenants (or existing tenants that turn on “Enable Seamless SSO” in the tenant advanced options) behave differently: if the user already has a session in place then the login step is skipped completely so that the hosted login page is not even displayed (although the user might see other prompts such as MFA or consent).
When this “Seamless SSO” functionality is enabled (which, again, is the default and only behavior available on new tenants) the
404 , because its functionality is not really needed anymore.
Lock still tries to call
/user/ssodata anyway (because Lock, running in the browser, is unaware of the tenant configuration), but when getting a
404 response it simply assumes that there’s no session in place (which is the right assumption to make, because if there was a valid session then the login page would not have been loaded).
Now to follow up on the 400 Bad Request generated by a Cookie getting larger after each logout. From looking over the HAR file it appears you are using the Auth0 Google Dev keys in production, we would recommend generating a fresh set of keys from Google for your production use case. I have linked a supporting doc below that can help you on that front.
Please let me know if you have any additional questions on this front, thanks!