Therefore what I meant is that Cookies (traditionally called sessions) are a good way to go in web browsers (since they come built-in and are the most secure way of TRANSFERRING tokens). Other system may not support Cookies or are otherwise (e.g. Web View (Cordova/Phonegapp) apps) blocked from seeing Cookies may want to "manually" deal with the token (aka sending it back to the server on every authenticated request)
On the server you would traditionally have a store (a so called Session Store) to save the token<->user mapping. AKA When a user logs in, create a unique and random token for that user, save the binding/mapping in the Session Store and send the token as the response for the incoming login request back to the user (either in a Cookie header or some other header (Authorization header commonly used)).
Stateless tokens is the idea of encoding the user mapping (like a unique user id in your database that is plain text safe) within the token itself (meaning that you wouldn't have to check a Session Store on the server in order for you to know from what user that request is coming from).
There are problems with stateless tokens though, namely that you cannot revoke access to that token (only the expiry date will expire it) -- unless of course you incorporate a blacklisting system AKA a so called blacklist store -- then you would, for every incoming request, have to check the blacklist store to check if the token is blacklisted -- this of course pretty much defeats the entire purpose of stateless tokens -- since to begin with we wanted to skip the step of checking a store.
