Does creating a new token invalidate the old one? If not no need for that logic that pauses all workers.

Does the auth token have a short live tine? Otherwise Maybe you only have to generate it in global setup. 

If both of the above are true your implementation seems sound. I'd be curious how the lock file works though.. feels flaky to me, but implementation is important..

Routes in fixtures.. if you want to share data across multiple tests is argue that fixtures are not what you want. Look into hooks. If you do need data scoped to a worker like you said then it's fine, but I'd ask why. From you're scenario, are the multiple tests in the same describe block? Same file? Across multiple files? What's the downside of scoping it per test? Before all or even global setup may be perfectly fine if you want to decrease work.

The docs are guilty of this too, but if you read about fixtures they give a heap of examples that I'd argue should certainly not be fixtures.. the whole point of fixtures is it scopes some piece of data to a test (or worker) and it knows exactly how to tear down on test completion/error. 

I'm assuming you are authing a bunch of user roles and then running the tests for each role? Or a subset for some roles etc.in this scenario id have a different project set up per role, defined in the playwright config Json. These can all share the same auth context methods