Common web authentication methods

Sessions

Client - session cookies Server - session-state service/server/manager

problem:

• Memory issues: Whenever there are many authenticated users, the we server will consume more and more memory. Even if we use a file-bnased or external session provider, there will nonetheless be an intensive io, tcp, or socket overhead.
• Scalability issues: Replicating a session provider in a scalable web farm might not be an easy task and will often lead to bottlenecks or wasted resources.
• Cross-domain issues: Session cookies behave just like standard cookies, so they cannot be easily shard among different origins/domains. These kinds of problems can often be solved with some workarounds, yet they will often lead to insecure scenarios to make things work.
• Security issues: There is a wide and detailed literature of security-related issues involving sessions and session cokies:XSS attacks, cross-site request forgery etc. Most of them can be mitigated by some contermeasures, yet they can be diffcult to handle for first-hand developers.

Token (stateless)

Client - location storage / cookies Server - auth check

advantages: It won't store any user-specific information of the server memeory, database, session provider,or other data containers of any sort.

refresh token It is a special kind of token that can be used to obtain a renewed access token - that allows accessing a protected resource - at any time. You can request new access tokens until the refresh token is blacklisted. Refresh tokens must be stored securely by an application becuase they essentially allow a user to remain authenticated forever.

Signatures

Two-factor

• The user performs a standard login with a useranme and password
• The server identifies the user and prompts them with an additional , user-specific request that can be only satisfied by something obtained or obtainable throught a different channel: an OTP password sent by SMS, an unique authentication card with a number of answer codes, a dynamic PIN generated by a proprietary device or a mobile app, and so on
• If the user gives the correct answer, they get authenticated using a standard session-based or token-based method

Local storage vs Cookies

Local storage

Pros:

1. As localStorage is not sent automatically with every request, it is secure against any Cross-Site-Request-Forgery (CSRF) attacks attempting to run actions from external sites by making random requests
2. The localStorage is easy to read in JavaScript since it is stored as a key value pair
3. It supports a bigger data size, which is great for storing an application state or data

Cons:

1. localStorage is not transmitted on every request. When the page is loaded initially, you are not able to send the token within your request, and so resources needing authentication cannot be given back to you. When your application has finished loading, you have to make a second request to your server, including the token to access the secured content. This behavior has the consequence that it is not possible to build server-rendered applications.
2. The client needs to implement the mechanics to attach the token on every request to the server.
3. From the nature of localStorage, there is no built-in expiry date on the client. If at some point the token reaches its expiration date, it still exists on the client inside localStorage.
4. The localStorage is accessed through pure JavaScript and is therefore open to XSS attacks. If someone manages to integrate custom JavaScript in your code or site through unsanitized inputs, they are able to read the token from localStorage.

Cookies

Pros:

1. Server-side rendering is no problem at all since cookies are sent with every request
2. No further logic needs to be implemented in the front end to send the JWT.
3. Cookies can be declared as httpOnly, which means JavaScript can't access them. It secures our token from XSS attacks
4. Cookies have a built-in expiration date, which can be set to invalidate the cookie in the client browser
5. Cookies can be configured to be readable only from specific domains or paths.
6. All browsers support cookies

Cons:

1. Cookies are generally open to CSRF attacks, which are situations in which an external website makes requests to your API. They expect that you are authenticated and hope that they can execute actions on your behalf. We can't stop the cookie from being sent with each request to your domain. A common prevention tactic is to implement an CSRF token. This special token is also transmitted by your server and saved as a cookie. The external website cannot access the cookie with JavaScript since it is stored under a different domain. Your server does not read a token from the cookies that are transmitted with each request, but only from an HTTP header. This behavior guarantees that the token was sent by the JavaScript that was hosted on your application, because only this can have access to the token. Setting up the XSRF token for verification, however, introduces a lot of work.
2. Accessing and parsing cookies is not intuitive, because they are just stored as a big comma-separated string.
3. They can only store a small amount of data.