Authentication, authorization, sessions, cookies and JWT

Authentication, authorization, sessions, cookies and JWT

Differences between authentication and authorization

When talking about user validation in an app, we have two different terms to think about. Authentication stands for the process in which a user confirms it's identity either by providing an email and password, or any other method available (like login with social networks). On the other side, authorization is the process of checking if a user is allowed to access certain information.

Simply put, authentication is the process of verifying who someone is, whereas authorization is the process of verifying what specific applications, files, and data a user has access to.

Different authorization methods

Like mentioned before, for authentication we have the classic email and password, login with social networks and other methods to confirm the user identity.

With authorization, there're too various methods available. The two most common ones are sessions and cookies, and JWT.

Sessions and cookies

So think about this, when we need to decide whether a user is allowed to visit a page or not we first need to know who the user is, right? We do that by authentication (asking the user to create and account and login). But we need to store that information somewhere, if not we would need to require the user to login every single time he asks for a different page or information.

Session and cookies are a way to store information about a user that has logged in. The process is the following:

  • After login, the server creates a piece of information called session, which contains information about the user and a unique ID.
  • That session is stored in a database or the server memory, and then sent to the user in a cookie.
  • The user receives the cookie, and in every request sends it back to the server, who checks if the cookie received matches the information stored in its database or memory. If it matches the user is authorized, and if it doesn't it's not.

With this method we can know who the user is in each request, without the need for the user to log in more than once.

Done with cookies and sessions, the authorization process would look something like this:

image.png

JWT

JWT stands for Json web token and it's an encrypted piece of json formatted data. Using JWT authorization, the process is the following:

  • After login, the server creates a JWT that contains information about the user. This JWT is encrypted with a secret key only the server "knows".
  • The user receives the JWT, and in every request sends it back to the server, who decrypts the JWT and check if it matches its secret key. If it doesn't match, the user is unauthorized, and if it matches the user gets the authorization corresponding to its profile.

With JWT, nothing is stored on the server, all the user info is condensed on the JWT and stored on the client. The server doesn't have to store or look up anything. This also comes in handy when an application is running on multiple servers at a time. In this case the user can use the same JWT to get authorized in any server, without the need of servers to share any session information at all.

Done with JWT, the process would look like this:

image.png

How JWT are formed

A typical JWT would look something like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

You can see the token is made up of three different parts divided by points.

  • The first part contains information about the token type and the algorithm being used to encrypt it.
  • The second part contains the payload, or the information you have decided to insert in the token. In this example, the payload is sub(for subject) which contains the id of the user, the user name and iat (for issued at) which contains the date the token has been generated at.
  • The last part contains both previous parts combined with points and encoded in base64, and then encrypted by the algorithm previously declared and a secret key you've previously declared. This last part and the secret key is what allows your server to decode the JWT and confirm that the information it contains is valid. If any character of JWT was changed the decryption just wouldn't match what your server expects and the user would be unauthorized.

image.png

If my article was helpful, consider inviting me a coffee = )

Invitame un café en cafecito.app

Buy me a coffee

You can also follow me on Twitter and Linkedin