Access token or Sessions in Apis

Asked

Viewed 520 times

1

I am developing an api and I have a question about how to manipulate the logged in user. The logged in user api and administration (add things, edit profile, photos, etc.) is developed in Rails in a single project.

Because I have a very interactive part in this project, and I’m using React to consume the api. This part is a project the part that runs in a subdomain. Today I’m using sessions to identify the user’s state. Do you have a problem staying that way? Security? Performance? Cache?

Ex: The user logs in to www.dominio.com (Rails+API+Adm) and when he goes to.com project (Separate project) he remains logged in, making requests to GET www.dominio.com/api/v1/friends.json with specific results for that user. In the api I identify this user via session and not by Sting query and no parameter type.

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

In another project that I am developing in parallel, the api is with access_tokens, Entering only has the api, have nothing but the services in Rest.

ruby-on-rails api

  • I’d like to be home to answer your question. I’ll answer it by 9:00. For now, tell me how many simultaneous users your application intends to support. See more.

  • I don’t have a set number, but there would be several.. I saw that with the access token I have more flexibility to scale, right?

1 answer

1

JSON Web Tokens VS Sessions

If we’re talking about scalability, it is not possible to use only Sessions because the use of memory or I/What you will need is gigantic. Using only JWT, it doesn’t matter whether you have 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 status is persisted between several different devices. Meanwhile, using JWT can help you reduce network traffic and I/O operations. JWT can also be used to give you an application for Single Login, where the user credentials will only be used on the first login and then you will use authorization tokens to renew your normal tokens.

For your application have the state-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 customer side with the customer without being able to read that. You can add the current route, the path it traveled and persist in the database after, you can save the nomeDeUsuario or some random token used to identify the session.

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

Something important to note is that the design of your application should realize when it is necessary to make use of I/O, Sessions in-memory or JWT.

Two examples of my applications I can give you:

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

In this application, I didn’t care about much. The 50~100 sections were always in the RAM to ensure the status of users. A power outage and 'shawl'. Meanwhile, the users login only once and, after that, the server sent a JWT only with the username user, which was used to identify him and saved in cookies. The server trusted the encrypted JWT and took the username as true. Meanwhile, each login JWT was renewed for another week and, if it was expired, the server requested credentials.

  • 2) A learning application, a scalable game.

In this application, there were no sessions. The user simply creates the account, receives his JWT, which is stored in Local Storage and is logged in forever. Whenever he goes to the app, his account is identified and an I/O is made to create him a character to play based on previous matches. Whenever the player dies, another I/O is made to save some information about the match and the dead character.

Quick summary

Tokens

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

Sessions

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

Everything’s unsafe, I just left it as a reminder. ;)

Browser other questions tagged ruby-on-rails api

You are not signed in. Login or sign up in order to post.