Session vs Token Based Authentication
The Session and Token-based Authentication methods are used to make a server trust any request sent by an authenticated user over the internet. In this way, a user can interact with their account without continually specifying their credentials. These methods are usually used for different purposes.
For example, sessions are commonly used in websites applications while tokens are preferred in server-to-server connections.
A session is a small file, most likely in JSON format, that stores information about the user, such as a unique ID, time of login and expirations, and so on. It is generated and stored on the server so that the server can keep track of the user requests. The user receives some of these details, especially the ID, as cookies that will be sent with every new request, so that the server can recognize the ID and authorize the user’s requests.
- The user sends a login request to the server.
- The server authenticates the login request, sends a session to the database, and returns a cookie containing the session ID to the user.
- Now, the user sends new requests (with a cookie).
- The server checks in the database for the ID found in the cookie, if the ID is found it sends the requested pages to the user.
Since sessions are stored on the server, its administrators are in power over them. For example, if a security team suspects an account is compromised, they can immediately invalidate the session ID, so that the user is immediately logged out. On the other hand, since a session is stored on the server, the server is in charge of looking up the session ID that the user sends. This can cause scalability problems.
Cookies may be exposed to cross-site request forgery attacks. The attacker may mislead the user to a hostile website, where some JS scripts may exploit cookies to send malicious requests to the server. Another vulnerability regards the chances of a man-in-the-middle attack, where an attacker can intercept the session ID and perform harmful requests to the server.
A token is an authorization file that cannot be tampered with. It is generated by the server using a secret key, sent to and stored by the user in their local storage. Like in the case of cookies, the user sends this token to the server with every new request, so that the server can verify its signature and authorize the requests.
- The user sends a login request to the server.
- The server authorizes the login and sends a token to the user.
- Now, the user sends a new request(with a token).
- The server checks the token is valid or not, if the token is valid it sends the requested pages to the user.
Note- Those are not authentication files, they are authorization ones. While receiving a token, the server does not look up who the user is, it simply authorizes the user’s requests relying on the validity of the token.
Tokens can be useful when the user wants to reduce the number of times they must send their credential. In the case of server-to-server connections, using credentials becomes difficult, and tokens overcome this problem. Moreover, servers that use tokens can improve their performances, because they do not need to continuously look through all the session details to authorize the user’s requests.
However, the authentication details are stored on the client, so the server cannot perform certain security operations as in the session method. As written above, the server does not authenticate the user, so linking a token to its user can be more difficult. If a hypothetical attacker manages to get a valid token, they may have unlimited access to the server databases. If the server generates keys using older algorithms, these keys can be breached.
Differences Between Session and Token-Based Authentication Methods
Session authentication method
|Token-based authentication method|
|1.||Which side of the connection stores the authentication details||Server||User|
|2.||What the user sends to the server to have their requests authorized||A cookie||The token itself|
|3.||What the server does to authorize users’ requests||Looking up in its databases to find the right session thanks to the ID the user sends with a cookie||Decrypting the user’s token and verifying its signature|
|4.||Can the server admins perform securities operations like logging users out, changing their details, etc||Yes, because the session is stored on the server||No, because the token is stored on the user’s machine|
|5.||From what kind of attacks the method may suffer||Man-in-the-middle, Cross-site request forgery||Man-in-the-middle, Token steal, breaches of the secret key|
|6.||Preferred method application||User-to-server connections||Server-to-server connections|
- Session and token-based are two authentication methods that allow a server to trust all the requests it receives from a user. The main difference is session-based authentication of the connection stores the authentication details. The session method makes the server store most of the details, while in the case of the token-based one the client stores them.
- The session authentication method is based on the concept of the ID being shared with the client through a cookie file, while the rest of the details are on the session file, stored on the server.
- The token-based authentication method is based on the concept that possessing a token is the only thing that a user needs to have their requests authorized by the server, which must only verify a signature. The token is secure to use because it cannot be tampered with.
- Both methods have inherent vulnerabilities that can be most easily resolved with different workarounds. In the end, developers must decide which method suits better to their needs and applications.
Please Login to comment...