• Addresses Cons. A session ID is generated to track the user’s status during their visit
  • The session ID is recorded both Server and in the Client
  • On Client side, it is stored inside Cookie. This is the name origin for Session-Cookie
  • On Server side, it is stored in the server Main Memory or an independent session server
  • Users must still provide their username and password initially, after which the server creates a session for the user’s visit. Subsequent requests include the cookie, allowing the server to compare client-side and server-side session IDs
  • codeforces.com uses Session-Cookie Authentication, the cookie name is JSESSIONID


Improved Security

  • Usually comes with TTL, and the token value has no relationship with the user password. So when a session token is leaked, the risk of data loss is smaller


XSS Attack

  • The session Cookie can be hijacked by XSS attack which injects malicious scripts to send the session cookie to the hacker

CSRF Attack

  • Hackers deceive users’ browsers into unknowingly executing actions on websites. Hackers create malicious sites or emails with links to the targeted site. When users click the link, their browser sends a request with their session Cookie, making the server believe it’s a genuine user request
  • Websites can use anti-CSRF tokens or demand re-authentication for sensitive tasks to counter CSRF Attack

Hard to Scale

  • Each Session-Cookie Authentication requires server-side storage of the session state. This can become a performance bottleneck as the number of users and sessions grows

Non-mobile Friendly

  • Mobile app developers must directly manage cookies using the available APIs