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?