At its core, the idea is very simple. From an eli5 perspective, something like a JWT (JSON Web Token), is essentially an automatically generated passphrase.
When your client (like a Web app or mobile app) downloads it, it has to be done in a safe way, over an encrypted connection like HTTPS, so that no one else gets access to it. That's like whispering the passphrase to someone, so no one else can hear it. It also has to be kept in a safe place, so someone doesn't find a clever way to steal it! On the Web, that means you have to be careful of various attacks like xss and csrf.
Later, your client can access resources on the server by sending this token along with a request (also over an encrypted connection). That's like saying the passphrase to enter the secret guild of the magicians circle. Only someone who knows it can enter.
Difference between token and password
What's the difference between a token and an actual password? The difference is that the token can store additional information. For example, when the token is generated, the server can store the user's userid in the token, along with other information, such as a date for the token to expire, and any number of other things. This is done in a cryptographically secure way. In principle, it should not be possible for anyone who has the token to change this information. That means the client can use the token to access resources, but the client can't modify the token to get more access than what the server assigned to them. If you get a magician's apprentice token, you can't access the parts of the magician's circle meant for the master magicians.
However, the contents of the token are visible to the client, so the server should not include information inside the token that the client is not allowed to see. In general, avoid including any spells in the token itself!
Stateless communication
Why do we need this? The basic idea is that it should help you to build stateless communication between the client and the server. All of the information the server needs to authenticate and also to authorize the client is stored in the token. That means the server doesn't need to store that information in a session on the server.
Statelessness is desirable, because it means every request from a client to the server could theoretically go through a different server, without the issue of sticky sessions. That makes scaling much easier. Continuing our analogy, when you say the passphrase at the entrance to the magician's circle, it automatically identifies who you are, and where you're allowed to go, as well as whether your privileges are valid or have expired. That means the lackey at the entrance doesn't need to consult a separate book to get that info when you say your passphrase. You can use the token to enter at different chapters of the magicians circle, anywhere in the world!
I should say that in practice, unfortunately this picture of statelessness can get messy, but that's the overall concept.
Persistent Login
Another case where tokens come in handy is persistent login. Many apps these days will have you log in once with your real password, and after that you will be logged into that app automatically for a period of time.
This could be achieved by caching your actual password in the app. This is a big no-no however, An app should never store your password. This would mean that if someone manages to steal that stored password, your account would be permanently compromised.
Instead, a token can be used. When you log in with your password for the first time, the server will generate a token and return it to the app, which will store it locally in the most secure way possible. From then on, the token can be used to log into the app until the token expires.
If the token is stolen, that's not great, but it's a bit less serious than compromising the password. You'd still need to use the password to make any significant changes to your account, so the thief would not be able to make permanent or catastrophic changes. Also, once the token expires, the thief would no longer be able to use your account, unless of course they found a way to steal the next token you received!
Bachelor's and Master's in CS from MIT. Previously, worked @ Microsoft & Zynga. Currently Co-Founder of Moesif (moesif.com), the most advanced API analytics platform.
Top comments (3)
At its core, the idea is very simple. From an eli5 perspective, something like a JWT (JSON Web Token), is essentially an automatically generated passphrase.
When your client (like a Web app or mobile app) downloads it, it has to be done in a safe way, over an encrypted connection like HTTPS, so that no one else gets access to it. That's like whispering the passphrase to someone, so no one else can hear it. It also has to be kept in a safe place, so someone doesn't find a clever way to steal it! On the Web, that means you have to be careful of various attacks like xss and csrf.
Later, your client can access resources on the server by sending this token along with a request (also over an encrypted connection). That's like saying the passphrase to enter the secret guild of the magicians circle. Only someone who knows it can enter.
Difference between token and password
What's the difference between a token and an actual password? The difference is that the token can store additional information. For example, when the token is generated, the server can store the user's userid in the token, along with other information, such as a date for the token to expire, and any number of other things. This is done in a cryptographically secure way. In principle, it should not be possible for anyone who has the token to change this information. That means the client can use the token to access resources, but the client can't modify the token to get more access than what the server assigned to them. If you get a magician's apprentice token, you can't access the parts of the magician's circle meant for the master magicians.
However, the contents of the token are visible to the client, so the server should not include information inside the token that the client is not allowed to see. In general, avoid including any spells in the token itself!
Stateless communication
Why do we need this? The basic idea is that it should help you to build stateless communication between the client and the server. All of the information the server needs to authenticate and also to authorize the client is stored in the token. That means the server doesn't need to store that information in a session on the server.
Statelessness is desirable, because it means every request from a client to the server could theoretically go through a different server, without the issue of sticky sessions. That makes scaling much easier. Continuing our analogy, when you say the passphrase at the entrance to the magician's circle, it automatically identifies who you are, and where you're allowed to go, as well as whether your privileges are valid or have expired. That means the lackey at the entrance doesn't need to consult a separate book to get that info when you say your passphrase. You can use the token to enter at different chapters of the magicians circle, anywhere in the world!
I should say that in practice, unfortunately this picture of statelessness can get messy, but that's the overall concept.
Persistent Login
Another case where tokens come in handy is persistent login. Many apps these days will have you log in once with your real password, and after that you will be logged into that app automatically for a period of time.
This could be achieved by caching your actual password in the app. This is a big no-no however, An app should never store your password. This would mean that if someone manages to steal that stored password, your account would be permanently compromised.
Instead, a token can be used. When you log in with your password for the first time, the server will generate a token and return it to the app, which will store it locally in the most secure way possible. From then on, the token can be used to log into the app until the token expires.
If the token is stolen, that's not great, but it's a bit less serious than compromising the password. You'd still need to use the password to make any significant changes to your account, so the thief would not be able to make permanent or catastrophic changes. Also, once the token expires, the thief would no longer be able to use your account, unless of course they found a way to steal the next token you received!
this isn't a ELI5, but I think my co-worker wrote one of the most popular articles on this subject:
moesif.com/blog/technical/restful-...
Very interesting, thanks