Hi folks, I’m coming from REST and currently think...

# graphql

[Felix Honer]

Hi folks, I’m coming from REST and currently thinking about how to handle jwt authentication between webapp (browser) and graphql api server in a good way. ⬇️

[Felix Honer]

The very basic approach is to call a graphql mutation which will respond an access token which then can be used by the webapp e.g. through authorization header. To keep the token on the client one could store it in the localstorage. Now I don’t like this approach because the localstorage is available from anywhere in javascript, which makes it a potential security risk if you think about XSS.
To get rid if this you could also - instead of transferring the access token in the response body - respond with a set-cookie header with httpOnly flag and let the browser set it as the request header automatically, so the token is not accessible through javascript. Also a known practice is to keep the lifetime of the access_token short and provide another refresh_token to get a new access_token in case it expired. In REST you would set the refresh_token as a httpOnly cookie as well but also with a certain path, that is only used for gaining a new access_token by the refresh_token. And that’s my point when it comes to GraphQL, where you only have one single endpoint and the refresh_token cookie won’t work in that way anymore.
Is it common to still have a dedicated endpoint for creating access/refresh tokens or are there any other best practices? I couldn’t find very much on the internet about this, maybe you have some links or opinions to share. Thanks!