Invalid login token. Token expired Issues and Unwanted Local Storage in Brave Browser

@ottokruse, this is a resolved issue, but has information that might help others, so I’m not immediately closing it. Feel free to do so whenever it seems right.

In testing we discovered a persistent situation where an a@edge installation using a Cloudfront alternative domain would fail with an error of the form Invalid login token. Token expired:.

• The alternative domain had previously been part of another a@edge install
• The problem did not occur with a new alternate domain
• The problem did not occur with no alternate domain, e.g. raw CloudFront URL
• The problem could be resolved by removing the alternate domain and reverting to Cloudfront URL (by cloudformation update, so that everything in a@edge was kept in sync)

Turns out the solution is simple …

• a@edge creates a long lived ID token that is stored in a browser’s local storage.
• The token is stored under the domain of the web application – in the case the alternate domain --, not the AWS or Cognito domain, which can be confusing
• The token is not exactly a cookie, it’s a local storage item, sometimes called Web Storage
• Finally, and most fun, not all browsers clear local storage when you select the “Clear all cookies” item. Brave is one such browser

So, if this happens to you, find the ID token ‘cookie’ in local storage associated with the alternate domain, and delete it. Here’s one example:

Interestingly, clearing this token also seems to resolve the failed logout seen in #94, not sure why.

[rpattcorner]

Wrapup

I think we’ve got a handle on this issue now, and want to document what we’ve learned in case others stray down this particular rabbit hole.

Cutting to the chase, the problem at its core was that the logout chain resulted in Cognito loading a cached version of the app held in local storage. The cached version failed multiple CSP tests that would be passed by a version loaded from Cloudfront. The simple solution is on the application side:

window.localStorage.clear();

Do this just before you redirect to the /signout URL that calls the signout lambda. Duh.

But we also took some time to switch to the Amplify framework so we could explicitly initialize storage with cookie (not local) storage. Both changes were probably necessary.

Finally, in passing, the way that some browsers show cookies and local storage can be confusing to the uninitiated (that’s me 😃). For example, Brave, my current favorite shows a cookie and storage display like this:

which led me to think the cookies were being somehow stored in local storage. I now think this is probably false. The cookies may (?) be just fine, the way to parse the line is “17 cookies. And also some local storage.”

Hope this is helpful to somebody down the road.

[rpattcorner]

And yet (referring to a 19th century critique of the bumblebee), the current setup works.

I guess the question is whether we can configure the CognitoSDK to use cookies (which I’d prefer) while retaining the simplicity of the default Cognito interface, which seems to require neither Amplify or a CognitoSDK instantiation of a UserPool with explicit cookie-based storage. You’d think there would be an option on the UserPool itself…