2

Imagine you have a website, for which you have configured a proper and secure session management / login system, using first-party / session cookies. Any interaction with that website is setup in the form of a REST API, so there are no HTML forms or similar; every interaction is a REST API request. Consequently, the entire session management (session expiry, session ID regeneration, etc.) has been setup in a way compatible with a stateless approach.

Your customer now requires you to build a mobile app for the existing platform, with the same login logic + features available.

If your web login logic uses secure-only HTTP-only cookies, and you send all requests from your mobile app through HTTPS; do you see any problem / risk in simply using the session cookies of the web platform as the auth tokens of the mobile app, as soon as authenticated? E.g. when you login in the mobile app backend, simply extract the session cookie header from the usual web login response, and send that to the mobile app user, and store it there to authenticate further mobile app requests. Any risk / problem with this?

I know that there are other session management approaches, like JWT, but using JWT doesn't free you from keeping state. You still need something like a session store to check tokens against. You would also need to keep a blacklist of invalidated tokens if you want to support users logging out or invalidate tokens after a user changes their password.

As this entire logic has already been setup for the web platform via cookies, I'm just wondering why we should not use the same authentication logic (cookies, simply stored in the secure storage of the mobile device and only decrypted upon request) for the mobile app, as the mobile app is also supposed to consume the same REST API in the same way?

Improve this question
6
  • Are you sending auth tokens or session tokens over un-encrypted HTTP on either web app or mobile app? If the answer is yes ... you have a pretty large problem.
    – CaffeineAddiction
    Commented Oct 18, 2023 at 17:49
  • @CaffeineAddiction: From my understanding the OP clearly states that HTTPS is used: "uses secure-only HTTP-only cookies ... all requests from your mobile app through HTTPS"
    – Steffen Ullrich
    Commented Oct 18, 2023 at 18:04
  • 3
    From my understanding you basically ask if it is ok to do what the browser does: send the session cookie back to prove that the next request is part of the authenticated session. Of course, session cookies should have a life time so that it is not sufficient to store it once after login but you need to update the local copy whenever the server sends you a new session cookie. As long as you use HTTPS and do not expose the session cookie further this should be fine.
    – Steffen Ullrich
    Commented Oct 18, 2023 at 18:08
  • @CaffeineAddiction The answer to your question is obviously no :)
    – DevelJoe
    Commented Oct 18, 2023 at 19:20
  • @SteffenUllrich cheers, was my understanding too. Was just wondering why most or pretty much all online session management docs / tutorials talk about tokens and none talks about the simple re-use of your session cookies (if expiries etc. are handled in a stateless way on your server, which is of course a big IF, maybe that's the reason why...). Just wanted to double-check, cheers!
    – DevelJoe
    Commented Oct 18, 2023 at 19:21

1 Answer 1

Reset to default
1

do you see any problem / risk in simply using the session cookies of the web platform as the auth tokens of the mobile app, as soon as authenticated?

No. Using cookies for authentication can be secure, both in a browser and in a mobile app. There is no reason to use another authentication system for the mobile app.

Things to consider:

  • Store the session token (the cookie value) securely, such as in the keystore of the device.
  • How to handle session timeouts.
  • How to handle CSRF protection. The mobile app is not vulnerable to CSRF, but the API probably has CSRF protection to avoid CSRF attacks through browsers.
Improve this answer

You must log in to answer this question.

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