JWT storage

[charlie17]

Another question for you Alex (feel free to move/delete from here if more appropriate): Can you say a few words about how the auth JWT tokens are being stored with this approach? localStorage, regular cookie, HttpOnly? Any security matters to be conscious of if using this approach in production?

[chiubaca]

Yes sure. You should be able to see the JWT in your cookies, this I believe is generated by go-true automatically. The src code never actually uses this cookie directly. We take the parsed payload of the JWT (which the gotrue lib does for you) and persist this into local storage so that we have easy access to the users FaunaDB token which was embeded in the JWT.

Depending on who you ask, you should only persist senstive data in the browser for as long as it's required as local storage might be susceptibleto XSS attack. If I was to critically evaluate the security of this app, I would say that persisting the FaunaDB user token in local storage is a potential vulnerability. Take that as you will. If this is a concern it might be better save this token in a cookie instead so that you can benefit from some addtional web security. This would require some refactoring though which I have not really dug into. I've been thinking about doing a Vue 3 version of this demo which can probably address this.

[charlie17]

Thanks much. I wrote up the following in my own notes. I appreciate you wrote up some good summaries in the blog post and in the code itself, all of which was helpful. This is just to pull everything together in my own mind. Anything here that is off track?

1. At successful new user signup, a Netlify/GoTrue account is created (id, email and pw are stored there), and a corresponding Fauna user document is created (id and full_name stored there)
2. Fauna provides back a DB access token specific to that user, which is then saved back to Netlify/GoTrue as persistent metadata alongside the user's id, email and pw (Note: A separate, random pw is created to facilitate getting the DB access token out of Fauna. This happens one time only, at user creation)
3. At future logins, Netlify/GoTrue validates email/pw credentials, and if successful, provides back a JWT and, embedded within the JWT, that same Fauna DB access token as well
4. That JWT is managed by Netlify/GoTrue and is stored in an http-only cookie. The JWT changes with each login. The Fauna DB access token remains the same for a given user from session to session
5. We never use that cookie directly in our code. But once we get the DB token back, we are putting it into local storage for ease of use, for as long as the user is logged in. This is the only potential security vulnerability. A future (Vue 3) version of the project may address this by saving the DB token itself in a cookie rather than local storage

1-2 above are handled in identity-signup.js (Netlify function)
3-5 above are handled in auth.js (Vuex module)

[chiubaca]

Yeah, you nailed it. This is summerised much better than I could have written!
Also worth noting that steps 1-2 have a slightly different auth flow when authenticating via external providers e.g Google. This is handled by identity-external-signup.js. This function has to be invoked manually, the vuex action is in auth.js

[plondon]

@charlie17 nice write up!

[charlie17]

@chiubaca Curious for your thoughts - what would the argument be against just using Fauna auth across the board, rather than the combo of Fauna + Netlify/GoTrue, as we do here? Any relative tradeoffs?

[chiubaca]

The main tradeoff/consideration I can think think of is that you're tightly coupling your auth to Fauna. If you ever wanted to switch databases this could be an issue.

This repo explores that pattern if you're interested - https://github.com/ptpaterson/netlify-faunadb-graphql-auth.