CookieStorage with httpOnly 2021 edition

[philipjames44]

Is your feature request related to a problem? Please describe.
Yes, amplify should support httpOnly cookie setting via Cognito to prevent a user from manually having to create httpOnly cookies to prevent XSS attacks, and so that using a custom API does not require the user to store JWTs in localStorage.

Describe the solution you'd like
Boolean flag to add httpOnly cookie in cookieStorage by leveraging the backend infra of Cognito.

Describe alternatives you've considered
Creating my own cookies. I cannot store my relevant cookies server side or use API gateway so it must be stored securely on the client. I can use localStorage to store JWTs but httpOnly cookies are the more secure solution.

Additional context
This is a follow up on #3224, which I believe was closed prematurely.

[philipjames44]

Bump.

[Eduard-Hasa]

Bump. Much needed now especially with nextjs 12 middleware authentication capabilities

[justinphilpott]

Curious if anything will happen with this...

[moneebalalfi]

@justinphilpott Me too! found something! ?

[fab-mindflow]

Bump too.

[JoeyAtSS]

Bump

[davemooreuws]

Hey all,

I have decided to create a httpOnly cookie solution for amplify auth. @philipjames44

Feel free to check it out: https://github.com/nitrictech/amplify-secure-js

It's new and we are open to contributors.

[ovidb]

We've ended up using patch-package to modify the AWS Amplify library to support this but it becomes one of those things you have to remember about when you update Amplify. An official solution to this would actually make a lot of sense.

[philipjames44]

This really feels like it should exist out of the box. We've since created our own solution for this problem, but it is ridiculous amplify is offered as a product without http only cookies

[parthNJ]

Please bump this up, this is one of the most frustrating things I've encounter. If possible, please amplify team add the HttpOnly flag.

[abdallahshaban557]

Hello Everyone, we understand this it is frustrating that we do not have this feature available from AWS Amplify and Amazon Cognito. We do not have an immediate solution to this issue, however, we are discussing internally what we can do to support this in a future iteration of our Amplify Auth category.

[electronicbits]

I came across this thread today as I am facing similar issues, ie. safely storing the JWT in the client => unsecure localstorage vs cookies not having HTTPOnly flag.
Has anyone thought about using API Gateway as a proxy for Cognito ?
There is a chance one may be able to use API Gateway to set the HttpOnly flag, potentially solving this issue.
Added to this, you may get the added benefit of monitoring request/responses to cognito using cloudwatch.
The lambdas would be simple proxy code that receives the request and send it to Cognito, then the response is sent back to the client with the cookies + flag
It may be a bit overkill for some, specially if you are not using API Gateway as part of your infrastructure already.
We are using it, so this is something we plan to investigate ASAP.
Anyone knows the pros/cons regarding this approach ?

[jhoffmcd]

@electronicbits I have done something like this in the past and it can work. This precludes you from using the Amplify client SDK though, so all those helpful features and functions are things you will have to build yourself. You'll have to look into authorization too, something like https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html. Seems like more work, but potentially also more control and security in that you can set things how you want.

[electronicbits]

@jhoffmcd thanks for that !
Doing a bit of research, I found this link which explains how to improve cognito by in fact placing API Gateway as a proxy:
https://aws.amazon.com/blogs/architecture/enriching-amazon-cognito-features-with-an-amazon-api-gateway-proxy/
The author states that if you follow this pattern, you can even send an encrypted version of the JWT token to the client so they can't bypass the API Gateway and call cognito public url directly. The decryption obviously happens in the proxy lambda.

[electronicbits]

Just noticed, the cognito app client has already a secret in place. Meaning all requests with no secret will be rejected.

[john-at-mc]

Bumping this as well, a native solution would be greatly appreciated!

[ckifer]

Bump again, this is blocking

[fab-mindflow]

Bump too.

[philipjames44]

In a few short weeks the issue title will need to be updated to a 2023 edition 😬

[fab-mindflow]

🤣 Bump bump bump. Any plan?

[fab-mindflow]

Hello Everyone, we understand this it is frustrating that we do not have this feature available from AWS Amplify and Amazon Cognito. We do not have an immediate solution to this issue, however, we are discussing internally what we can do to support this in a future iteration of our Amplify Auth category.

What was the result of those discussions?

[BorntraegerMarc]

For anyone that's looking for a work-around solution: You might find my official AWS blog post helpful: Reduce risk by implementing HttpOnly cookie authentication in Amazon API Gateway

It's also using Amazon Cognito.

[fjcalzado]

@BorntraegerMarc thanks for the post. Your solution implies using a hosted UI to allow Apps to be as agnostic as possible from the authentication flow (effectivley, removing amplify dependency and with it, client-side token storage), right?

That makes total sense to me, but, what if a custom login UI is needed? Is there a way to securely achieve this use case?

[BorntraegerMarc]

@fjcalzado you can customize the Amazon Cognito sign-in page as described here: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-app-ui-customization.html

[pudasainimiraj]

Bump!

[TE-RobertMcCain]

For anyone that's looking for a work-around solution: You might find my official AWS blog post helpful: Reduce risk by implementing HttpOnly cookie authentication in Amazon API Gateway

It's also using Amazon Cognito.

Thanks @BorntraegerMarc !! I followed the steps in the article you posted and I have this working and authenticating the sample lambda function. Now... How do i make this authenticate my amplify application? Also, I need to use the AWS.Lambda and AWS.S3 libraries which both require the accessKeyId, the secretAccessKey and the sessionToken. How would I get these using the technique you described.

I came across this library that seems perfect but it is incompatible with my project
https://github.com/nitrictech/amplify-secure-js

[BorntraegerMarc]

@TE-RobertMcCain for amplify (any SPA) you can just redirect to Cognito hosted login page on login. No further action needed

[louislatreille]

I'm hoping folks in this thread can help me understand what I'm missing. After reading on this topic and experimenting with AmplifyJS, I don't see how supporting httpOnly cookies would solve all XSS surface.

It seems like to support httpOnly cookies, the Amplify team would have to write an Amplify backend, where cookies would be set. For most functions that we call on the client-side, a request would be made to that backend, which would then make the request to the required AWS service.

In theory, the above could be possible, probably with a new "Amplify backend" service that we would have to deploy. This would be the exact same as writing our own frontend code and backend server, but obviously would save us a lot of code to write. But for some Amplify libraries, this wouldn't even remove the XSS vulnerability. Take the geo or the pubsub libraries. I'm fairly sure those need to be used directly from the client-side. This means that the tokens would need to be exchanged between the backend and the frontend, essentially voiding the use of httpOnly cookies.

I feel like we're trying to add capabilities to a framework that has been inherently designed to run with some vulnerabilities. I.e. Amplify JS has been designed to make requests from the client-side of frontend applications, using Cognito tokens.

For everybody that claims having implemented httpOnly cookies through a work-around (SSR, API Gateway, or something else), are you able to use the geo or pubsub modules securely? I'm under the impression that this isn't the case.

Again, I'm hoping somebody proves me wrong, as I'm not an expert on security or frontend frameworks. I would very much like to use AmplifyJS, securely, as it saves me writing a lot of code.

[srgg]

Is there any update on this?

It would be so great to get this fixed. I assume this is due to security unawareness. Lots of applications are affected by this just because they realize on Amplify UI. As far as I can tell there is no explicit warning about this security issue in Amplify UI documents.

[cordev-developer]

Hey guys, I agree with your comments, as @louislatreille says, what if we need to use geo or pubsub features ?, maybe it is need a solution that's Amplify team sure will find. I will check also the libraries commented (https://github.com/nitrictech/amplify-secure-js), it looks good and as soon as possible I will check it with React.

[UwUPower]

Bump. It is very much needed.

[faif]

Bump

[mateuspadua]

Bump

[lucasdu4rte]

Bump

[noahpeden]

Bump, we could really use this.

[owhittlef]

Bump! This just came up on a pentest report for me.

[jonathanbodart]

Bump. Also came up as a pentest findings in our Team.

We had some hope reading this piece of documentation from Amplify but could it be the snippet is not working for Gen2 (@aws-amplify/auth) ?

[minoru761]

Bump, we could really use this, too.

[sclee-micehub]

Bump, we need to implement OpenID Session Management using Amplify Gen2 with Next.js adapter, right now.