browser automated test requiring multiple logins of different accounts

try to logout the legitimate way (automate hitting the button)

or wipe cookies?

shouldnt both do the same thing?
wiping cookies means once ur page refreshes ur auto logged out

clicking logout button should wipe cookies, empty storage and refresh

@azuredivay wiping cookies makes the browser 'lose' the 'access card'. But it doesn't not remove that 'card' from the server-side registry.

I'd argue that the former is more important.

Why not both?

Log out, assert that both the cookie store and the session database is empty. If they aren't, fail the test and wipe both manually before the next one.

What lorentz said, but instead of cleaning up manually between tests, run each test in a brand new browser using a WebDriver API

@netikras you mean refresh token cleanup? usually dont they too have an expiry on the server side? say 30 days
So if you delete the RT on the client side, and it's unused, it'll anyway be booted out a few weeks later

and RTs aren't that easy to guess either, neither would any normal auth-service allow you to brute-force them
So is deleting RTs on the server side, then-and-there, that important? //honest question

@azuredivay i meant sessionId and similar cookies.

JWT - eh... Devs don't usually bother to implement a proper logout procedure for jwt-managed sessions. But mechanisms are still possible to implement: have a registry of revoked access and refresh tokens.

As for the WHY -- consider a leaked token. Say, you added your both tokens in a unittest and forgot about them and pushed 'em to public github. Aaaand you're fucked if the backend does not invalidate tokens upon logout [should you invoke it]. Anyone can access and use your refresh token for ~30days to create new access tokens and basically use your credentials forever

@magicMirror Agreed. Or, write a test to ensure that cookies are truly wiped after clicking the logout button.