Access token or Sessions in APIs

1

I'm developing an api and I'm having a question about how to handle the logged-in user. The user's logon api and administration (add things, edit profile, photos, etc.) is developed in Rails in a single project.

As I have a very interactive part in this project, I'm using React to consume api. This part is a separate project that runs on a subdomain. Today I'm using sessions to identify the status of the user. Is it any problem to continue like this? Safety? Performance? Cache?

Ex: The user logs into www.domain.com (Rails + API + Adm) and when it goes to project.domain.com (separate project) it remains logged in, making requests to GET www.domain.com/api/ v1 / amigos.json with results specific to that user. In api I identify this user via session and not by query sting and any kind of parameter.

Another question: When the user logs in, could I create an access_token and store it in session, so that it navigates and queries that access_token in the api? Deleted as soon as my api has to query the session and query through access_token.

In another project I'm developing in parallel, api is with access_tokens, but only has the api, have nothing other than services in rest.

    
asked by anonymous 04.12.2015 / 14:52

1 answer

1

JSON Web Tokens VS Sessions

If we're talking about scalability , you can not use only Sessions because the memory or I / O you'll need is gigantic. Using only JWT, so much has 10, 100 or 100 million users, but not everything is just sweet.

The hybrid model is usually the best. You can persist sessions so that your user's state is persisted between several different devices. In the meantime, using JWT can help you reduce network traffic and I / O operations. JWT can also be used to give you an application of Single Sign-On , where user credentials will only be used on the first login, and then you will use authorization tokens to renew your regular tokens.

For your application to have the status maintained , just sign your JWT with some information relevant to the user's status. Remember that JWT can store any information you want on the client side with the client without being able to read it. You can add the current route, the path it has traveled, and persist in the database later, you can either save the nomeDeUsuario or some random token used to identify the session.

On network traffic , as you add information to JWT, it grows, and as a result, data traffic grows. It is necessary to realize that each strategy has a negative point, being the use of the processor to decode the tokens the negative of the JWT. Meanwhile, the negative side of sessions is the use of I / O and RAM .

One thing to note is that design of your application should realize when you need to use I / O, sessions in-memory, or JWT.

  

Two examples of what I can do for you:

  • 1) A business application for 50 ~ 100 people with little access.

In this application, I did not care much. The 50 ~ 100 sections were always in RAM to ensure the status of the users. A fall of energy and 'xablau'. In the meantime, users logged in only once, and after that, the server sent a JWT with only the username of the user, which was used to identify and save it in cookies. The server relied on encrypted JWT and took the username as true. Meanwhile, with each login JWT was renewed for another week and, if it was overdue, the server requested the credentials.

  • 2) A learning application, a scalable game.

In this application, there were no sessions. You simply create the account, get your JWT, which is stored in the Local Storage and stays logged in forever. Whenever he goes to the application, his account is identified and an I / O is made to create a character to play based on the previous games. Whenever the player dies, another I / O is done to save some information about the match and the dead character.

  

Quick Overview

Tokens

  • Standardized by RFC 7519 .
  • Quite compatible with mobile devices.
  • It consumes more CPU, but less RAM
  • Unsafe.
  • Born to be small and keep logged in with single login.
  • Stored on client, processed on server.

Sessions

  • Although not standardized, it is widely used.
  • Workarounds for dealing with mobile.
  • Consumes more RAM and I / O, but less CPU.
  • Unsafe.
  • Born to 'keep logged in'.
  • Stored on the server.

Everything is insecure, just left as a reminder. ;)

    
06.12.2015 / 13:47