Cookie*- Maintain the active state of the browser by storing a bit of data between the **server and the client** with every request.*
Session*- Record the **server and client session state**.*
Token- A random string generated by the server*.*
This article is tailored for those who are looking for a basic understanding of what sessions, tokens, and cookies are, how they work, and why they exist.
When you log into a website, you declare who you are (identification). Your identity is verified (authentication), and you are granted the necessary permissions (authorization). Many solutions have been proposed in the past, and the list keeps growing.
Authentication
Authentication is the act of verifying user credentials in terms of either correctness or time.
Correctness: The user credentials are verified based on existing details. At the sign-in request, an authentication token is assigned to the user. It will be used to authorize the user and authenticate subsequent interactions with the application.
Time: The authentication token assigned to the user is only valid for a specific period of time. If the token becomes invalid, the user needs to be re-authenticated before access can be granted.
The term “authentication token” is used here to describe any form of authentication credential that might be implemented by the application, not explicitly an access token.
Why use authentication
There are two reasons why authentication is necessary to allow full access to an application:
Authentication establishes the identity of the user and verifies that the user is who (or what) it says it is. Authentication protects your resources by denying access to unauthenticated users.
Authentication gives each user a distinct identity, protecting your data and theirs. Applications that require users to create an account give each user a unique profile, which is what determines the data shown to the user.
For example, PayPal or any payment portal requires users to sign in before displaying their account balance and transactions.
Generally, the process works like this:
You sign in.
The server verifies your sign-in details and assigns you an authentication token.
The authentication token is used to make a request to your homepage that displays your unique dashboard.
Both session cookies and access tokens allow users to make requests to the server without needing to re-authenticate at each request.
Sessions
When thinking of building out a website, a session is all interactions made by a user within a timeframe. This time could be set to be a certain period before the session expires, or even until the user closes out the webpage. A session could include a variety of activities, such as searches, scrolling, clicking through links, or even filling out web forms. It can be anything if it represents the time a visitor spends on the website. Any activity on that website is recorded through the session ID.
A session ID is used to store the data server-side. However, session IDs are also used for users’ privacy, as the ID can be passed instead of login or other sensitive information. By gathering information, data on how the website is used can be viewed. This information aids in creating better user experiences, which may even be personalised and tailored to the users. That session ID is still tied to a timeframe, however, so at some specified point, it will expire.
When we think about a session expiring, this means that the user has exceeded the duration that the developer-defined in their code. Sessions can be brief periods, such as how a bank will timeout if you are inactive for more than a few minutes, or they could be set as a longer period, such as an entire day. Inside the session, information from the first arrival until the session ends is recorded. Because a session refers to a certain duration of time, a single user can have multiple sessions within a short period. For example, if we think of the banking example, after a period of inactivity the page times out and logs you out. But if it does log you out, you could log back in almost right away, which would create a new session. Another example is that a computer can open multiple tabs. This means you could be looking at a series of different websites, all of which are considered sessions for the different websites. But what if you decide to open a page on the same website in a new tab or new window? Would that generate a new session ID? Not exactly. That’s where cookies come in.
Cookies
If information about your session is going to be stored, something must temporarily retain that data. A cookie is a small file that stores pieces of data gathered in a session. For example, when segments, addresses, or passwords are automatically filled in, it is because there is a cookie holding that information. It is also what can be gathered from a session to let the website see where you clicked or what you did during your session. Cookies allow you to stay logged in even if you exit the page.
As you’ve likely seen a thousand times when visiting a website, you can choose to “allow cookies” for a website or to ignore them when prompted. This means you can choose to not allow those cookies. But that does not mean something will not collect data. If you check your browser, it collects cookies as well as makes a cache of your visited websites. You can choose to clear those, but you may find yourself having to fill out your usernames that are otherwise usually saved. The cookies found on websites are first-party cookies, which are used to track just your session on the website to tailor/personalise your visit.
If your Facebook ads are looking suspiciously close to your Google searches, you may have found third-party ads. Third-party ads are typically stored inside cookies, and sometimes they can be enabled without even clicking on the ad. These are the types of cookies that draw privacy concerns. They can track not only the activity on the website you got them from, but they can track your browsing history in general.
One even more difficult third-party cookie is a zombie cookie. They are more difficult because they are often invisible, and even after being deleted, they can reappear.
Stateful cookies
Stateful cookies contain a pointer to a database record that stores the session information.
Pros:
Have no limitations on the amount of session information stored.
Can easily clear a user’s session -just remove the record from the database.
Cons:
Requires a database to store the session data (but most web applications already have this).
Increases latency because you have to make database calls to read the session (and sometimes write it) for each HTTP request a user makes.
Stateless cookies
Stateless cookies are self-contained; they include all session information that you need (for authenticated users, the user ID) and reside on the client. To prevent external tampering, stateless cookies should be encrypted (or at least signed).
Pros:
Reduces latency because you don’t have to call a database.
They require little storage
They reduce manipulation by client-side JavaScript
Cookies use the same session across subdomains
Cons:
Makes it difficult to revoke a session, because there is no record in a database you can delete, you’ll need to find other methods to forcefully clear a session.
If using multiple web servers, must make sure all servers have the key to encrypt/decrypt or sign the cookie.
Not good for API authentication
Cross-site request forgery attacks (XSRF or CSRF)
Cookies aren’t the only way to store session IDs; other options include URLs and form fields. Cookies are more secure than those two, but how secure are cookies?
- Cookies are only secure in an HTTPS connection. Enforcing the Secure flag ensures that cookies are only sent via an encrypted HTTPS connection. The use of HTTPS prevents disclosure of session ID in person-in-the-middle (MITM) attacks.
While cookies can be made secure by setting the appropriate attributes and following best practices, they can also be made insecure by neglecting these steps.
Because of these other types of cookies and the chance for security breaches, many people opt out of all cookies. Privacy can be more important than the ease of login. But what if you’re designing a website and all this cookie talk has you nervous? What’s the solution to have “sessions” without the need for “cookies”? That’s where tokens come in.
Tokens
Tokens are a self-contained and compact way to securely transfer sensitive information between two parties. The composition of a token includes the header, which defines the type and algorithm used, the payload, which carries the metadata from the user much like a cookie would gather, and a signature, which is used to verify the identity of the sender. In this transmission type, the algorithm is used to secure the information by encoding it. It also does not require the use of cookies, because a token can be stored in Web Storage instead. This is either local storage or session storage. If a token is tampered with, it can be either revoked or blacklisted, which furthers its security.
In a session, a server must store the state, for example, if it is still active and ongoing. With tokens, the state is not stored. It is self-contained and therefore contains all the required information for authentication.
An example of a popular token system is JSON Web Tokens (JWT). A JSON Web Token is encoded using Base64, but this does not mean they are encrypted. The message is available for viewing, but only if they have the secret. There is a secret to decode the message, and without the secret or with the incorrect secret the message would be useless.
Process:
The server generates a token value by using a hashing algorithm and then returns the token value to the client when the user logs in successfully for the first time.
After the client gets the token value, it stores it locally
When the client requests again, it attaches the token value to the request and sends it to the server
After the server receives the client’s request, it will extract the token value and compare it with the token value stored locally on the server
Token value from client = Token value from the server-The user is logged in successfully
Token value =/ token value from the server — The original login information has expired, and the user is required to log in again
No such token value — the login is not successful
Tokens Are Signed, Not Encrypted
A JSON Web Token is comprised of three parts: the header, payload, and signature. The format of a JWT is header.payload.signature.
JWTs are cryptographically signed and base64-encoded. They’re only secure when they aren’t exposed, so they should be treated like passwords.
A JWT can be viewed but not manipulated on the client side. You can take your token to jwt.io, choose the algorithm you used to sign, and see the data. You just can’t tamper with it because it’s issued on the server.
The lifespan of a JWT should be kept short to limit the risk caused by a leaked token.
{
"sub": "67554887",
"name": "Alpha",
"admin": true
}
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwi
bmFtZSI6IkFkbyBLdWtpYyIsImFkbWluIjp0cnVlLCJpYXQiOjE0NjQyOTc4ODV9.
Y47kJvnHzU9qeJIN48_bVna6O0EDFiMiQ9LpNVDFymM
What is SSO?
Single sign-on (SSO) is a centralized session and user authentication service in which one set of login credentials can be used to access multiple applications. Its beauty is in its simplicity; the service authenticates you on one designated platform, enabling you to then use a variety of services without having to log in and out each time.
In the most common arrangement, the identity provider and service provider establishes a trust relationship by exchanging digital certificates and metadata and communicating with one another via open standards such as Security Assertion Markup Language (SAML), OAuth, or OpenID.
Single sign-on example
Imagine you’re the user in an environment with a single sign-on and you’re trying to get access to some resource on a server. The sequence of events for how SSO works go like this:
You attempt to access the service provider- again, this generally is an application or website you want to access.
As part of a request to authenticate the user, the service provider sends a token that contains some information about you, like your email address, to the identity provider, a role played by your SSO system.
The identity provider first checks to see whether you’ve already been authenticated, in which case it will grant you access to the service provider application and skip to step 5.
If you haven’t logged in, you’ll be prompted to do so by providing whatever credentials the identity provider requests.
Once these credentials have been validated, the identity provider will send a token back to the service provider, confirming that it’s authenticated with you.
This token is passed through your browser to the service provider.
Once received, the token is validated according to the trust relationship that was set up between the service provider and the identity provider during the initial configuration.
The user is granted access to the service provider.
Some common SSO protocols include:
Security access markup language (SAML): SAML is an XML-based open standard for transmitting user information.
Open Authorization (OAuth): OAuth is an open standard to transmit user information without revealing the password.
Kerberos: Kerberos issues a ticket-granting ticket (TGT) for every valid user authentication. Both the user and server identify each other with tickets issued by the TGT. This makes it the ideal standard for untrusted networks.
OpenID Connect: OpenID Connect is built on top of OAuth 2.0. It is fast gaining traction for being easier to implement than SAML. Since it works with restful application programming interfaces (APIs), it is an ideal choice for mobile applications.
Smart card authentication: This involves smart cards loaded with cryptographic keys. When plugged into a computer, pre-loaded software interacts with it and authenticates the user. It is expensive and is usually used in addition to other modes of authentication.
OAuth
OAuth is an open-standard authorization protocol or framework that describes how unrelated servers and services can safely allow authenticated access to their assets without actually sharing the initial, related, single logon credential. In authentication parlance, this is known as secure, third-party, user-agent, delegated authorization.
It is also helpful to remember that OAuth is about authorization in particular and not directly about authentication. Authentication is the process of a user/subject proving its ownership of a presented identity, by providing a password or some other uniquely owned or presented factor. Authorization is the process of letting a subject access resources after successful authentication, oftentimes somewhere else. Many people think that OAuth stands for open authentication, but it’s more helpful to understand it by thinking about it as open Authorization.
Additionally, OAuth 2.0 is a framework, not a protocol (like version 1.0).
How OAuth works
Let’s assume a user has already signed into one website or service (OAuth only works using HTTPS). The user then initiates a feature/transaction that needs to access another unrelated site or service. The following happens (greatly simplified):
The first website connects to the second website on behalf of the user, using OAuth, providing the user’s verified identity.
The second site generates a one-time token and a one-time secret unique to the transaction and parties involved.
The first site gives this token and secret to the initiating user’s client software.
The client’s software presents the request token and secret to their authorization provider (which may or may not be the second site).
If not already authenticated to the authorization provider, the client may be asked to authenticate. After authentication, the client is asked to approve the authorization transaction to the second website.
The user approves (or their software silently approves) a particular transaction type at the first website.
The user is given an approved access token (notice it’s no longer a request token).
The user gives the approved access token to the first website.
The first website gives the access token to the second website as proof of authentication on behalf of the user.
The second website lets the first website access its site on behalf of the user.
The user sees a completed transaction occurring.
Conclusion
As we learned, sessions are durations of time that a user spends on a website and includes everything that they do in that timeframe such as clicking on different pages or filling out a form. Sessions give you the ability to track what the user is doing in their time on the website. You collect that information to personalize the user’s experience, or even to learn more about what the typical user is doing on your website and what may or may not be getting clicks. However, a session only tracks the user instead of storing the data. For this, you need cookies. Cookies are small files that hold all the information gathered about the user’s experiences during a session. They are what store the data to allow it to be used later. Cookies can be enabled automatically, but many websites choose to prompt the user to allow for cookies. However, browser and third-party cookies also exist which are not in control of the website and can be more harmful in terms of user privacy.
Instead of a session, tokens can be generated as a secure way to track user information and activities. Tokens can also use cookies, but they can avoid cookies with web storage. One way to store the data is with JSON Web Tokens (JWTs). These tokens are stored in a JSON file and are encoded using Base64, which means a secret is required to decode the message. Without that secret, the message is meaningless. It is an alternative to the session/cookie route, and tokens can even be signed by third parties.