“How are you supposed to implement token-based authentication?”
Simple, you don’t. Either that or the ‘cookies’ become user-access objects not available to system processes or programs. The user would need to initiate use of cached information rather than the system and cookies.
Brave likely relies on a one-time session ticket requiring the website to do the identity caching -which most do anyways. No persistent caching. More work for the user and the website but more privacy and security too.
I am not talking about session data. I am talking about an identification token (encrypted and unchangeable — altering token is detectable by server if using HMAC IIRC). It has to be stored client-side somehow (unless you pass the password on every request, which is a bad idea all the way around). How does the browser send a server-generated token on requests, if there is no way to store that token client-side? I am genuinely curious, and always looking for a better way. I thought the current best practices pattern was: 1) user sends password once, over ssl; 2) server creates unchangeable and unreadable token that acts like a session key; 3) server sends token as a cookie; 4) client sends cookie with each subsequent request.
Is there a better/safer way? I know that HTML5 session store and local store were supposed to supersede cookies, but they aren’t yet ready for prime time, or so I thought.