I want to implement a login into my C++ desktop application and I'm having a hard time finding information on managing login sessions without cookies or JWT (JSON Web Token) (more on that in a bit). I can send HTTP requests from my C++ app just fine as well as incorporate TCP sockets if needed.

Here's a typical user workflow:

  1. Register for an account on my website.
  2. Pay for access to a desktop application.
  3. Download and log in to the desktop application.
  4. Desktop application sends data (~1MB) to server API to be processed.
  5. If the user is authenticated and has sufficient funds, processed data is returned.

Some requirements:

  • Session storage so users don't have to log in every time.
  • Close all other sessions if a log in occurs from a different IP.
  • Ability to log in to the website to view usage stats and edit account info.

Because of those requirements, I shouldn't use a JWT because I can't revoke or invalidate tokens without storing sessions server-side anyway. I also can't use cookies because the log in is not (always) happening in a browser.

Almost every guide or tutorial I've found online for MERN (Mongo, Express, React and NodeJS) stack authentication and session handling involves either tokens or cookies. I want to use neither.

How would I begin to implement server-side sessions management and user authentication inside a Node app when the log in can happen from a browser OR a desktop application?

Thanks for your time!

2 Answers 2


I also can't use cookies because the log in is not (always) happening in a browser.

Why not? Cookies are not magical things; they are a header sent by the HTTP server. Most libraries, such as curl, support storing cookies.

Close all other sessions if a log in occurs from a different IP.


Companies may have load balancing outgoing proxies. Users may switch between wifi and 4G on their laptop. At the very least, you should limit it to switching within the same net block (e.g. at least /24).


When the desktop application logs in at the server, at the server create a guid/token/authorization key and store it in the database together with the associated account. Then return the token to the desktop application. The desktop application stores the token (maybe even permanently in a file or registry). With every request it sends the token to the server. The server looks up/checks in the database the associated account (and if the token is deleted) and checks the funds and processes the request. If the session should be closed/ended mark the token deleted in the database.

You can also use the tokens in cookies for authentification.

Btw. binding sessions to an IP-address is a bad idea like mentioned many times on this site like when the user switches between mobile internet and landline internet or for many other different reasons.

You must log in to answer this question.

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