When using a non-MVC service-oriented/Interactor pattern approach to decoupled system architecture, how is session state implemented?
I've been thinking of building the frontend of an application using MVC (PHP/Ruby etc.), and send messages to a command-line backend which is the actual application. Since I want the offline application to be completely in control of functionality I would imagine using an offline session management system to work best, which at login issues an ID that is thereafter sent to the application on every request. The ID would be stored in a cookie on the client-side, just like a regular session cookie. Since the frontend works through HTTP requests anyway it makes little sense to do it any other way to me.
Are there any better alternatives to this method that I should consider? I would prefer to keep the actual system completely decoupled from the web UI and also plan on implementing a desktop UI aswell, so the Interactor pattern seems to be the best way to achieve this to me. What I'm explicitly trying to avoid is the "do everything in our MVC framework! (and be stuck forever)" that seems to be popular nowadays.