I have a GraphQL endpoint (express-apollo + prisma) that I am trying to secure with Auth0. I have a decoupled frontend app that needs to authenticate in order to be able to access the endpoint. For security reasons, I CANNOT (refuse to) store the JWT sent from Auth0 to the client anyplace except in an httpOnly secure cookie. I have yet to find a way to poke the Auth0 API into passing JWTs directly to customers as httpOnly secure cookies. As such, I suspect I need to have the client hit a /login and /register route on my server, so that the server can request the JWT directly from Auth0, then package it into a cookie to pass to the client.
I am experiencing some difficulty implementing this (currently I get a “failed to fetch user profile” error from Auth0 upon login attempt, so I wanted to reach out on here and see if someone can point me in the right direction as to which of the recommended “login flows” I should be using for this case.
On a side note, also wishing to provide some general feedback to Auth0 - I am left somewhat dumbfounded and disheartened that Auth0 recommends not storing JWTs in localstorage:
yet most of Auth0’s docs and tutorials use localstorage to set tokens received from Auth0, particularly when it comes to the auth flows recommended for decoupled front end applications. It is contradictory and Auth0 is most certainly not promoting security best practices in their tutorials. I’d appreciate hearing from someone at Auth0 on this seemingly problematic situation.
Terribly sorry for such delay in response! We’re doing our best in providing the best developer support experience out there, but sometimes our bandwidth is just not enough for all the questions that are coming in. Sorry for the inconvenience!
Yes, I would like someone to provide an answer to my question. Indeed I find it rather odd that you wrote me to ask if I would still like an answer rather than simply answering. That approach is super in efficient and a time waster for us both. No wonder y’all are having a hard time keeping up. Clearly, I wouldn’t have taken time to draft and carefully craft my thoughtful question if I wasn’t expecting a thoughtful answer in return – of which I still have yet to receive 7 MONTHS later.
TBH it has been so long since I have tried to get support from you that we have kind of given up on using your service until you start providing clearer answers to these security concerns in your documentation – which is also a hodgepodge mess of outdated material. It is difficult to get any clear answers from your company on implementing the services you offer. I can attest that it has certainly left us frustrated.
We had a similar question at our company and initially went down the secure cookie route, but then decided against it.
1 - We are using header based authentication.
2 - The access token is available to the client when logging in so even if the token is in a secure cookie, the client has other ways to read the value
3 - Auth0 documentation says to store the token in memory and not local-storage (this part seems strange to me to be honest)
4 - we opted to store this in a client side cookie
Why are you dogmatic against storing the access token in anything other than a secure cookie? (this really only makes sense if you are doing cookie based authentication)
Hi @konrad.sopala - we’re bumping into the same issue. Any update on how we can set an httponly cookie? If we call the Lock widget, it handles the authentication and invokes our .js callback. However, the .js callback can’t set the cookie due to the httponly flag. The documentation indicates it requires using a “Form Post Response Model”, but it doesn’t really delve into how the cookie would be secured:
Placing the token in LocalStorage, SessionStorage, or a general auth header isn’t an option as it exposes the token to malicious client-side javascript. Placing the token in the query string similarly exposes it to an admin with access to view web logs. Cookies with secure and httponly flags direct the browser to enforce security measures to only send over HTTPS and prevent access by malicious scripts. Any guidance would be helpful.
Terribly sorry for the delay in response but it must have got trapped somewhere in between all the incoming questions. Once more sorry for the inconvenience!
I managed to discuss that with our engineering team and here are their thoughts:
HttpOnly cookies can only be set by the server and can only be read by the same server. No javascript code, including Lock.js, can read or write an HttpOnly cookie
In order to use the Form Post Response Mode you need a backend to receive the form post, that backend will then create and manage its own session with the browser using cookies and these cookies can be HttpOnly. We provide various SDKs to enable this, including express-openid-connect to add this functionality to an express server.
