Currently, I have a website that logs users in, and then keeps track of ther session using PHPs $_SESSION. I'm trying to transfer this to an android app, which means I can't use sessions to keep track of a users login. I was thinking that one way to get around this would be to generate a long authentication token on the server when the user's phone first logs in, which would then be stored on the phone. This could then be passed in the URL of any requests from the phone to the server, allowing the phone to acccess the user's data. How secure would this approach be?

  • 1
    Exactly the same as a cookie. If you called that token PHPSESSID and sent it into a Cookie header, it would be a PHP session. – LSerni Feb 19 '17 at 22:53
  • @LSerni So could I just let php generate this session id, read it from the phone, and send it manually with each request? – penalosa Feb 19 '17 at 22:57
  • Why not. You can put it in some header of your choice (e.g. SESSID) and read it back from PHP; I think it would be then placed in $_SERVER['HTTP_X_SESSID']. – LSerni Feb 19 '17 at 23:01
  • @LSerni How secure would it be to store this on the phone and use it as a persistent login token ( so the user doesn't have to log in every time )? – penalosa Feb 19 '17 at 23:04
  • Secure against which scenario? In general, I'd say it's as secure as the least secure between the phone, the connection, and the server. You really want to do this through HTTPS. As for the phone... you could store a PIN, server side, ask it of the phone, and check that it matches with the session; or possibly you could do this with a gesture. Get the gesture from the user, transmit it to the server, verify it matches with the stored authentication gesture connected to that user's "cookie". – LSerni Feb 19 '17 at 23:09

Use JWTs: https://jwt.io/, they are in my opinion the best way to manage sessions, especially in API based communications. They also let you send any arbitrary info in the encrypted token, great for logging and debugging.

There is a PHP here that works well: https://github.com/firebase/php-jwt


It's safe, it's like $_SESSION.

But the server must ignore the token if a user clicks on logout or changes passsword. Good idea is to use HTTPS and update tokens over some time.

If it is critical application, you can use second factor instead of username and password.

The token should not be based on weak pseudorandom number generator or generated by a cipher. It's not safety.

  • HTTPS is not just a good idea, it is absolutely essential. – Sean Burton Oct 12 '17 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.