Recently I was tasked with implementing a token based authentication structure for an API. When I initially looked it up, using tokens seemed almost identical to using sessions the way it was described in several articles. It took me quite a bit of reading before I finally understood what was going on, and I never did find a satisfactory explanation of how tokens differ from sessions. So today, I am going to attempt to clear up these murky waters a bit.
Sessions, Your Old Friend
If you have done web programming for at least a little while, you have probably come across sessions. Sessions are what the server holds on to, which allows the user to keep using the site without signing in every time their browser makes a request to the server.
Think of it as a business like a gym that has restricted access. If the gym used sessions, they might make you pay (sign in with password) when you show up each time and put your name on a access sheet. If you left and came back, they would ask for your name then look up and check (think database) whether you are allowed access or not.
The members (users) need to know their name (session id), the gym (server) needs to hold onto information about whether or not its members have access (session). For our purposes this represents the browser cookie with the session id and the session on the server.
Tokens, New Kid in Town
Although I had used tokens before, I had never implemented them into anything so I did not now exactly how they worked. (The particular kind of token that I am working with is a JSON Web Token but that is not actually important.) Like sessions, tokens also allow you to access the server without signing in every time. Unlike them, the server does not have them. Your user does.
Ok back to our gym example. Say that you want to give people 24 hour access to your gym and don’t want to have employees working the front desk at 4 AM to give people access. You could install a card reader at the door and then give out keycards that your gym members could swipe or hold up to it that allows them access. Once they pay (sign in with password), you give them a card (token) that they can come back with and you don’t have to look up on the sheet (database) whether or not they have access.
In this case the gym members (users) have all the information about whether or not they have access in the form of their cards (tokens), and the gym (server) simply validates the card when the member wants access. As a bonus, the local pool (a different website) has a card reader and a program that allows anybody who is a gym member to go swimming there. Members simply need to bring their cards (tokens). This is like OAuth/OAuth2 and signing in to websites using Google/Facebook/Twitter.
A Model For Understanding
Hopefully this gym membership model helped you understand the difference between token based authentication and session based authentication. If you want to learn more about specific implementation details, checkout some of the links below. And if you like what you read, sign up for my email list.
- JSON Web Tokens
- Token Based Authentication Made Easy
- Stack Exchange Discussion of Session Authentication vs Tokens
- Another Decent Explanation About Tokens