I deployed a simple Redwood app (baremetal) using dbAuth as the authentication method.
The cookie config in the auth.ts file is like this (Secure is set to false because I didn’t setup SSL):
I need an authentication and cookie to use with the graphql API. So I went to the login page and logged in with my username and password. After login, the server sent back a response, whose header contained a “Set-Cookie” string and body contained an id of the login user. Combining both, in other words, using “Set-Cookie” to construct a cookie and using the id to construct authentication, I can query the graphql endpoint by setting those values in the request header.
The problem is: after I logged out in the browser, which I expect will make the cookie invalid, I can still use the same cookie to query the graphql endpoint - so the cookie is still valid after logout, leaving a potential security hole.
This is the link to the same topic in Discord I posted earlier.
Since after setting up dbAuth, We can’t access the graphql endpoint if not authenticated. My understanding is that an authenticated request to the graphql endpoint is a request with three key-value pairs in the header:
a fixed key-value pair: Auth-Provider: dbAuth
an authentication key-value pair: Authentication: Beaer {id} where id is the id of the login user - This can be acquired by making a login post request to the auth API endpoint. The server will respond with a payload containing the id of the login user
a cookie key-value pair: Cookie: {session=xxx} where {session=xxx} can be acquired in the same response above - in the header of the response, there is a “Set-Cookie” field, and we can construct {session=xxx} from it
My question is how to make the cookie invalid, say when I have done using it and want to destroy it?
I found this post very similar to what I’m concerned about:
Logout functionality needs to handle both: remove the cookie from the client and terminate the session on the server. The latter is most important, or else the session remains valid even though the client no longer has the cookie. This seems not to happen in your case. Ask the developers to terminate the session on the server when a user logs out.
So you logged out and could still access a page for which you should be authenticated. This means that on logout the session is not terminated, which it should.
It sounds like what you’re doing is copying the cookie value, logging out on the client, and then making requests to the API manually using that cookie value, is that correct?
There is no “session” on the server to expire: it decrypts the value in the cookie and, if it’s valid, allows you to make GraphQL requests. The value that was in the cookie still decrypts properly, so the API considers it a valid request, whether or not it came from the browser.
If you needed to disallow a user to make requests (they get banned, for example) you would need to add a field to the database and then check it in the api/src/lib/auth.js function getCurrentUser(). If the user should no longer have access, return null and they’ll be considered the same as a logged out request.
It’s really no different than having an API key that a user can use to make requests: that API is good “forever” unless you take additional steps to limit its usage. This is the same as our other authentication providers that save a JST to LocalStorage: if you were to copy the value out of LocalStorage, log out, but provide the JST in the Authentication header, the request to the server would be considered valid.
Are you worried that a bad actor will somehow get your cookie from your machine and continue to make requests as you after logging out? This would be much less likely by using SSL and making the cookie secure.
Are you worried that a bad actor will somehow get your cookie from your machine and continue to make requests as you after logging out? This would be much less likely by using SSL and making the cookie secure.
I have really limited knowledge about cookies, authentication, etc - so this is indeed what I was worried about. Thank you very much for the clarification! Now I know this would be less likely by using SSL.