Mod 2 of flatiron school has been interesting. Our focus for the mod has been Rails.

What is Rails?

Rails is a framework built for ruby. It uses three main principles, MVC, convention over configuration and DRY(don’t repeat yourself). The aim of rails is to allow developers to build web applications quickly. Because Rails is for building web applications, it uses APIs to access the web. An API is an application programming interface. It is a set of programming instructions and standards for accessing a Web-based software application or Web tool. We access servers via API’s to view applications. By doing this we can create things called, cookies, sessions and tokens.

Sessions are small pieces of data that are stored on the server about the user eg. language preference. This allows information about the user to be accessed on-demand. However, this can be sensitive information, so we use cookies to create a unique hash that serves as an identifier for accessing the information. This protects sessions from being hacked. Cookies are saved on the users’ side. The attributes for sessions are dependant on the developer. You also get tokens which are similar to sessions but stored on the user’s side. Unlike sessions which are opaque, meaning 3rd parties can not have access to sessions, tokens can both opaque and self-contained, they store direct information and can information from them can be shared amongst servers.


Authentication is the process of verifying a user. Authorization is the process of verifying permissions of the user.


This refers to whether the state (the condition of an entity) is independent of the server’s response. A session using a cookie is stateful as the state of the session depends on the cookie the server generates. Whereas tokens or OAuth does not depend on the state of the server as they are saved on the user’s side and access can be shared amongst servers.

So let’s compare Session vs Token-based authentication

We have:

1. Session-based authentication

The flow:

  • Login credentials of a user are validated using a DB
  • A session is created and assigns a cookie a sessionID
  • The user sends cookies with each request
  • Depending on what the user sends authentication and authorization is granted
  • The session is then destroyed when the user logs out

This is the method we have been learning in Flatiron.

We can store sessions in the DB, cache or memory.

Session Cookies are prone to CSRF attacks(cross-referencing attacks ), when unauthorized actions take place on behalf of an authorized user.

It is more difficult to use sessions if you have lots of traffic.

2. Token-based authentication

The flow:

  • Login credentials of a user are validated using a DB
  • Generates temporary Token and embeds it with user data
  • Server responds back with a token that is embedded in the body, head or response
  • The user stores the token in client-side storage, which means it is passed to the browser’s storage
  • User sends token in requests
  • The server verifies token and authentication and authorization is granted
  • Logging out clears the token from the client’s storage

Because Tokens can be shared amongst Servers, NEVER store private information in the token.

Due to tokens being self-contained it can reduce the amount of DB lookups.

You usually get both refresh and access tokens.

If cookies are disabled, your website is still functional.

If you have to reset passwords, a list of blacklisted or whitelisted tokens must be kept and this defeats the purpose of tokens as it will be stateful.

JWT(JSON Web Tokens) tokens are a widely used form of token authentication.

This is an example of a JWT token

This is what the payload contains

In conclusion, session-based authentication is more secure than token-based authentication due to the fact sessions are saved on the server so it is more difficult to access information. However, in order to make sessions scalable, you have to use sticky sessions which balances the load. You should keep in mind that some of the most secure authentication methods use tokens rather than sessions, so decide on a case by case basis.