I get what you're asking but the implementation you're describing is remote authentication, not session state. Session state doesn't care whether the user is authenticated or not. You don't want sessions to require authentication generally.
Regardless, back to the question:
What you are interested in is Distributed Session State. Traditionally, this is usually achieved by 1 of 2 main approaches:
A distributed cache cluster that the callers can access remotely. Particular softwares that do this really depends on what languages you are working with.
or
Sessions get persisted to a back-end database and interactions are handled by a service or other proxy-type interface.
The caching implementation is the fastest, as is the nature of reading from memory (even when distributed) but sessions are not persisted through restarts, shutdowns or failures.
The database implementation is a bit slower but is fairly fault-tolerant since they are persisted to the database. To compensate for the speed difference, database implementations usually use in-memory tables within the database, as it speeds up reads significantly and careful planning of indexing must be used (to many unneeded index changes causes the indexes to actually be counter-productive).
Another approach you could consider would be handling session state management like a web-based service. This would allow you to completely decouple sessions from the application and adhere to the mvc principle of maintaining statelessness. The service could be called via anything that can make http requests (even jQuery or ajax if you choose) and all responsibility could be pushed to the client (so you can have your cake and eat it too:))
I'm actually planning on trying the latter approach just to see how large it could be expanded (I've got my sights set on a HPC backend using Casandra db and aiming for a cloud-like structuring of session services).
Either way, any of these approaches will allow you to have sessions for any channels your application offers, including desktop :)
I think session should be managed of Client side as far as possible in SPAs.In SOA , Mostly service are viewed as stateless and puting state logic inside it will be deviation. Servies ae meant to perform the task without botherig about sessions.
However maintaing session on client side increasese the complexity a lot.
Best Answer
If you really must have session handling in your API then the client would be responsible to handle the session_id and add it to the URL if required. How exactly to handle this would depend on your technology stack. For example Rails defaults to cookies but (if enabled) would also accept a _session_id parameter as part of the URL.
The relevant information normally stored in the cookie together with the session id then must be handled by the server. In Rails you would have to switch session storage from cookie storage to one of the server options like storing it in the database or memcached with the session_id as key.
But you should really think twice if you want to add this feature to your API. Being stateless will keep your API simpler and easier to maintain. If any possible it is preferable to let the client worry about state and send all necessary information with each request. (like using HTTP basic authentication instead of storing a current user in a session).