User Authentication: Cookies vs. Sessions vs. Tokens

devfish·2023년 3월 8일

Network

목록 보기

3/4

Cookies: Security Risks

Cookies are small text files that are stored on a user's computer by a web server. They are commonly used for session management and user authentication in web applications. While cookies provide a convenient way to manage user sessions, there are several security risks associated with their use. Here are some of the detailed security risks of using cookies:

Session hijacking: Cookies are often used to maintain session state between a user and a server. If an attacker gains access to a user's cookie, they can impersonate the user and gain unauthorized access to the application.
Cross-site scripting (XSS): Cookies are vulnerable to cross-site scripting attacks, where an attacker injects malicious code into a web page and steals a user's cookie.
Cross-site request forgery (CSRF): Cookies are vulnerable to CSRF attacks, where an attacker tricks a user's browser into making a request to a website without their knowledge or consent. If the user is authenticated, the request will be processed and the attacker can perform actions on behalf of the user.
Information leakage: Cookies can store sensitive information such as usernames, passwords, and session IDs. If an attacker gains access to a user's cookie, they can extract this information and use it to compromise the user's account.
Malware delivery: Cookies can be used to deliver malware to a user's computer. An attacker can inject malicious code into a cookie and use it to execute arbitrary code on the user's machine.

To mitigate these risks, it's important to use secure cookie settings such as setting the Secure flag and HttpOnly flag to prevent cross-site scripting attacks and session hijacking. It's also important to use additional security measures such as two-factor authentication and rate limiting to prevent CSRF attacks and protect against brute-force attacks. In general, it's important to be aware of the potential security risks associated with cookies and take steps to secure them properly.

Cookies + Sessions

Cookies are commonly used to store user authentication information, such as a session ID or user token, for identifying the user and allowing them to access restricted resources or perform actions on a website or application. However, using only cookies for authentication can pose security risks and limitations. Session-based authentication complements the use of cookies in storing user authentication information by providing an additional layer of security and control.

Some reasons why session-based authentication on top of cookies may be necessary:

Preventing CSRF attacks: Cookies are vulnerable to Cross-Site Request Forgery (CSRF) attacks, where an attacker tricks a user's browser into making a request to a website on behalf of the user. To prevent this, the server can generate a unique session ID for each user, store it server-side, and use it to validate requests coming from the client.
Session management: Cookies can expire, be deleted, or become corrupt, leading to the loss of user authentication information. By using a session-based authentication approach, the server can manage the session's lifetime and ensure that the user remains authenticated as long as the session is active.
Enhanced security: Sensitive user data (e.g. the user's password) can be kept on the server-side and not stored in cookies, which are more vulnerable to theft or tampering.
More control: Session-based authentication allows servers greater control over user access to resources since they can revoke session tokens or terminate sessions when necessary.

Token-Based Authentication

Access/Refresh Tokens

Access tokens are short-lived tokens used to authenticate and authorize API requests. They typically have a relatively short lifespan (e.g. a few minutes to a few hours, 24 hours at most) and must be renewed frequently. Using short-lived access tokens mitigates the risk of unauthorized access when the token is stolen or leaked.

Refresh tokens are long-lived tokens that are used to obtain new access tokens. They can be used to authenticate a user and obtain a new access token without requiring the user to log in again. Refresh tokens are typically longer-lived than access tokens (e.g. days or weeks) and can be used to obtain multiple access tokens.

The following are some key benefits of using access/refresh tokens:

Enhanced security: the risk of unauthorized access is reduced if a token is stolen or leaked. If an access token is compromised, it will only be valid for a short period of time, reducing the potential for misuse.
Improved scalability: By using short-lived access tokens, the authentication server can process more requests and scale more effectively. The use of long-lived refresh tokens reduces the number of times a user needs to authenticate, reducing the load on the authentication server.
Improved user experience: By using refresh tokens, users can remain authenticated for longer periods of time without needing to log in again, which provides a more seamless user experience.

In short, access and refresh tokens provide a more secure, scalable, and user-friendly approach to token-based authentication in web applications and APIs.

Key Advantage of Refresh Tokens

TL;DR: You can revoke refresh tokens in case they become compromised.

From StackOverflow:

One key advantage of refresh tokens that's being missed is that they are revokable, while the access token is not.

To authenticate the access token, only its signature is checked. This makes it extremely fast to authenticate, and allows authentication to be performed in a distributed manner by different services without needing to check with another server or database. This also means it needs to have a short expiration time in case it's compromised because it can't be revoked.

With refresh tokens, it's presumed that some database or authentication server needs to be contacted in order to generate a new access token. This means it's slow (relatively) and can't be done in a distributed manner. But the token can be revoked if the user account is compromised, or the user changes their password, or for any other reason.

If you want to just use an access token/api key you can. It just means you either have to lookup in a database to make sure the token is still valid, or set a short refresh rate and force the client to re-authenticate every time. If your application doesn't need the performance, or can tolerate re-authenticating frequently, or you don't care about revoking access tokens, then you don't need refresh tokens.

Sessions vs. Tokens

Using tokens unburdens servers from doing all the heavy lifting, with some tradeoff in control.

Pros and Cons of Tokens

Some of the core benefits of using a token-based authentication mechanism are:

It is stateless or self-contained. It helps you avoid the overhead of fetching session data from the data store.
It is scalable due to its stateless nature.

With that said, there are several downsides to going with the token-based approach:

The secret key on the server side has to be extremely safe & secure from prying eyes.
Cookies have a maximum size limit of 4096 bytes. Thus, it does not allow storing large tokens. Switching to localStorage poses even more security concerns. Not to mention, the increase in latency with larger request headers.
Not suitable for applications that allow longer sessions (eg. one week). Tokens (should) have a shorter lifespan and it can impact user experience.
Revoking the token immediately is a challenge.