I'm trying to login a user and, then, retrieve the user information like we do on a regular web app using php session.

I have searched some solutions but I couldn't find any answer for my problem/doubt.

I know that the best way of doing it is using tokens but I would like to know if there's any other way to do that with a minimum level of security. I wanted some sort of stateful authentication.

The answers I got were things like "create a token a store it in the server" but I would like to know if there are more options. I actually wanted to store the user in a session/cookie or something like that (if possible), but I haven't seen anything regarding that. I use session storage to save the email and send to the server every request the problem is that local storage alone is a big security risk but I think using tokens is a little bit too much for what I need.

When I successfully log in, I store the user in a session like this:


It saves the session but when I try to make another http request, it says:

Undefined array key "loggedin"

I tried to send the session id along with the request but doesn't work out either as the server seems not to be rememebering the session.

So my question is: Is maintening a session on server side not possible in this case? If so, do I have another option besides token? Should I store the token in the database or is there any other way of storing the token?

  • I know this might seem a basic question, but I really wanted to save the user session without having to use tokens.
    – Thiago G
    Commented Feb 9, 2021 at 19:03
  • 1
    When thinking about authentication mechanisms, ask yourself this question: "What is stopping a bad guy from submitting the same headers and taking over the victim's logged-in session?". If the attacker only needs to know the victim's email address in order to take over their session, then that's not security. You say "I really wanted to save the user session without having to use tokens". If by "token" we mean "some long random-looking value that an attacker would have a hard time guessing", then there is no alternative. Commented Feb 9, 2021 at 19:33
  • Yeah that makes sense, I was just wondering... that's what I had actually, I had just the email as is saved in local storage and making requests to the server passing the email as parameter (just prototyping) but I realised it could be easily manipulated, I tried, then, using sessions, but they didn't work either. Anyway thank you, Mike. I'm new to mobile development, It was just a curiosity, I was wodnering if I could ever try other aproaches besides token. Thank you once again and I'm sorry if the question was too basic.
    – Thiago G
    Commented Feb 9, 2021 at 19:39
  • I'll write up a proper answer below. Commented Feb 9, 2021 at 21:43
  • you can start a session variable with username and password hash... you can also use that for "remember me" type cookie. If the user attempts to change their password or e-mail you should not rely on this to authenticate. Instead require them to send username/password. (to avoid a stolen cookie being used to take control of the account.) For cookies set "same-site" attribute. Commented Feb 9, 2021 at 22:43

1 Answer 1


Security goal

Let's take a step back here and ask what security goal we are trying to achieve here. I think with any "login session" system the goal is the same, and comes in two parts:

  1. Initial login: the user proves that they are who they say they are; this is usually done with passwords, MFA, email confirmations, whatever.
  2. Maintaining the session: each subsequent request from the client to the server contains some proof that they are the same person that did the initial login, and not an attacker trying to hijack their session and pretend to be them.

The common way of achieving this is that upon successful login (step 1), the server gives the client some sort of long random-looking string (aka "an auth token"), and the client includes it in each subsequent request as the proof for step 2.

I say "common", but I'm not actually aware of any alternatives unless you want to get into TLS client certificates, or pre-shared API keys but those are a lot more effort and are not really "sessions" anymore.


There is a lot of variety for what counts as an "auth token", for example:

  • JSESSIONID (commonly seen with Tomcat servers)
  • custom session cookie
  • JWT tokens
  • Bearer tokens
  • some custom value in the Authorization: header

Each of these has their own pros and cons. For example if you do JWTs, then you need to worry about securely storing a signing key in the server. Or if you use a session cookie then you also need an XSRF token. But in a broad sense these all follow the pattern of the server issuing a random-looking token upon successful login that the client echos back with each request.

Session management

(Response to comments)

You getting into the complexity of session management. This is getting way outside the scope of a security question, but I'll answer it anyway.

Yes, in order to process a request, the server will need to know "stuff" about the user and their session. For example:

  • Username / email
  • What group / permissions / access controls they have
  • What time they logged in / when their session expires
  • Whether they logged in with just password, or with password + MFA (for example if you require "step-up" to access sensitive parts of the app).
  • What IP their session is from (maybe you want to enforce geoIP restrictions, or make sure they don't change to an IP halfway around the world part way through their session)
  • A lockout-count (for example if you're doing a per-session lockout)
  • etc, etc

As this is mostly security stuff, the server needs to be keeping track of this, rather than trusting the client to give the correct information. Debates about where and how the server should store these "session objects" are basically as old as the internet itself. The most common designs are:

  • Server-side in memory: could be as simple as global vars in your application, or as complex as an in-memory database that synchronizes across servers. Pros: high performance as no db calls are needed. Cons: can run out of server memory, hard to scale horizontally (adding more copies of your server behind a load balancer), you need to worry about clearing out data when sessions expire.
  • Server-side in database: make a db table for tracking sessions. Pros: scales nicely. Cons: slightly worse performance, you need to worry about clearing out data when sessions expire.
  • Client-side (aka "stateless): put all the session data into an encrypted JWT (aka "JWE") and get the user to hand it back to you with each request. Pros: high performance, does not consume any memory on the server, scales nicely. Cons: more complex to implement properly, extra bandwidth usage.

As I said, this is an age-old debate, so google something like "server side session management" and you'll get loads of people debating the best way to store session data.

  • Thank you for taking your time to elaborate this answer. That made me understand some aspects. I think the custom session cookie is the best for me with an XSRF token because I won't be needing any kind of "sophisticated auth system" but I I can't afford having just an email in plain text in my local storage either, which, as you know (better than I do) is vulnerable to all sorts of tampering.
    – Thiago G
    Commented Feb 9, 2021 at 22:30
  • I could also create a token and store it in the database with the user email, right? But I don't think it's a good approach tho as it will add unnecessary overload to the database, making database calls every request.
    – Thiago G
    Commented Feb 9, 2021 at 22:38
  • @ThiagoG *raises eyebrow* In order to do anything useful, I assume your application already needs to make database calls with each request? What's one more? Commented Feb 9, 2021 at 23:03
  • Hahahaha that's right. xD That was dumb of me. Then that's what I'm doing. I will create a token and save it to the database.
    – Thiago G
    Commented Feb 9, 2021 at 23:14
  • @ThiagoG I started writing up a non-snarky comment, then it got too long for a comment, so I added another section to my answer about state management. Commented Feb 9, 2021 at 23:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .