Comments (6)
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.
from cloudfront-authorization-at-edge.
Having tokens in LocalStorage could mess things up, if the JavaScript app is configured wrongly. If configured correctly for Auth@Edge, I would not expect any tokens to be stored in LocalStorage.
First note, Auth@Edge would never write to browser local storage -- server side code cannot do that, only JavaScript running in the browser can.
What I presume must have happened, is that your JavaScript was not initialized with cookieStorage - and Amplify (/Cognito identity SDK) by default uses localstorage. So this became mixed up.
So to configure your Amplify JavaScript App for cookieStorage (instead of localStorage) use code such as:
Amplify.configure({
Auth: {
...
cookieStorage: {
path: "/",
expires: "",
domain: "your.domain.name.here",
secure: true,
},
...
}
});
The Cognito Identity SDK also support this setting (don't know from the top of my head what it is called but the key is using CookieStorage instead of the default LocalStorage).
Does that make sense?
from cloudfront-authorization-at-edge.
It does. We're not using Amplify - I'm increasingly convinced we should have done, but it would mean a significant refactoring. Cognito Identity SDK does indeed have something similar, per the pattern below, but I see nothing similar in our code, and our Angular developer is on another gig, so it may need to wait. Apparently you set the storage mode when you call a factory (?) to get the userPool, and again when you construct the userData object.
from the api doc:
var poolData = {
UserPoolId : '...', // Your user pool id here
ClientId : '...' // Your client id here
Storage: new AmazonCognitoIdentity.CookieStorage({domain: ".yourdomain.com"})
};
var userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData);
var userData = {
Username: 'username',
Pool: userPool,
Storage: new AmazonCognitoIdentity.CookieStorage({domain: ".yourdomain.com"})
};
Thanks for pointing us in a potentially good direction
from cloudfront-authorization-at-edge.
@ottokruse It looks like setting the cookieStorage (in either API) depends upon a style of initiating authentication as some kind of context in the root of the app.
Do you think that means that a different approach that simply uses the JWT supplied by a default cognito hosted ui login, to update the app's AWS.config object with the AWS.CognitoIdentityCredentials received direct from Cognito has the downside of disallowing a configuration that uses cookies instead of the default local storage?
What mischief do you suppose using local storage instead of ordinary cookies might generate over and above having to manually destroy the local storage when an alt domain changes?
from cloudfront-authorization-at-edge.
The Auth@Edge solution needs cookies.
Reason: browsers send cookies along automatically in requests to the web server - so Lambda@Edge can inspect the tokens in the cookies.
Whatever is in local storage is not send along automatically by browsers to the web server. Usually your JavaScript app uses tokens from local storage when doing XHR requests to protected API's (and you have to explicitly code that, i.e. add the token as header on those XHR requests). This is another paradigm, Auth@Edge is not (only) about protecting XHR, but (primarily) about protecting the SPA from being downloaded in the first place (as main web page).
If you configure you Amplify/CognitoSDK enabled web app with cookie storage from the get go, so it can work with Auth@Edge, you will never have JWTs in localstorage that you need to clean. Not that it matters a whole lot to change later: if you configure Amplify/CognitoSDK for cookieStorage then they will ignore tokens in local storage, and try to get (and save) tokens in cookies.
from cloudfront-authorization-at-edge.
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...
from cloudfront-authorization-at-edge.
Related Issues (20)
- Possible Open Redirect (CWE-601) in sample code HOT 2
- nonce cookies are not expired HOT 1
- [Feature request] Support multiple Cognito user pool clients HOT 4
- custom domain is not redirecting to cognito hosted ui HOT 1
- Getting blocked by CORS policy but unable to figure out the source HOT 5
- Node version bump HOT 7
- Custom IDP with Amplify and Auth at Edge HOT 9
- Fail on delete of the stack HOT 3
- Function must be in an Active state error on deploying the solution HOT 7
- Errors from Lambda when destroiyng the stack HOT 2
- Cognito TAGS HOT 1
- How Do I add User Pool attributes to Cookies? HOT 1
- A potential risk in cloudfront-authorization-at-edge which can be used to upload malicious code. HOT 4
- Having the ability to tune logs HOT 1
- Deployment to eu-west-2 fails with error: Encountered a permissions error performing a tagging operation HOT 4
- Missing User-Agent header in Post request to cognito HOT 4
- Question: redirecting after download from S3 HOT 2
- 'JavaScript heap out of memory' when running npm run build HOT 4
- Sign in, signout and then sign in again gets stuck at parse auth HOT 4
- Access denied from static S3 website after successful login HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cloudfront-authorization-at-edge.