Interesting your question!
(This suggestion is not for mission-critical or sensitive data applications, banking apps etc - so be careful where you use this ok?!)
EASY SOLUTION:
I’ll give you a hint: use a simple layer of encryption, a PIN, purely and simply. This helps and does not interfere in anything and combined with a symmetric key algorithm of the years 80/90, without being AES.
When creating the user’s registration, you ask them to create a 4-digit numeric password (a pin) The PIN you save in the user’s registration in the bank. The first time you generate the first token and CIPHER that token and guard.
User (id, email, passwd, pin, token) (a structure similar to this)
Very well, you will not store the pin in the desktop system. Only in the remote bank.
When you first log in, the API will return the encrypted token (if you pass authentication).
Every time the subject enters through the desktop, will have to enter the pin (the pin vc never stores locally), at that time vc sends a request to the authentication API saying: I have this pin and this token, check there hehehehe...
The API will decrypt the token using the pin as key, if hitting, hallelujah ;-)
On the desktop side you will store the encrypted token :-D only with the encrypted token, stored in a file, has some degree of protection.
(oh God, now I saw that your question is 2 years old! But ... since I wrote everything, follow the suggestion)
MARKET SOLUTION:
Use certificates, asymmetric key exchanges, correctly variable initialization vectors with synchronization functions.
Ensure both HTTPS transport in your API as well as preferred AES encryption of an elliptic curve-based algorithm. This is a course, can not answer here, please understand me: it is quite complex, but if this is your case, let’s go.
First step: Understand how to generate pair of keys on both the client and server side.
Public keys are exchanged between user and server: the user’s public key "goes up" to the authenticator and the public key of the "authenticator" goes down to the client.
Basically, the client’s private key NEVER goes up on the server. Never. If this happens it compromises the security and never the server’s PRIVATE key will stop on any client, if this happens, the security and integrity of the authentication server, will be totally compromised.
Still, we didn’t get there. Your system would store a CERTIFICATE. And the authentication would use the CERTIFICATE and not a password. This certificate would authorize the user. There depending on the case, could or not be "selfsigned" but for systems of high security, self-signed certificates without a certification entity, are not accepted.
Is there any restriction on you not using the token idea similar to what it would be with the web application? The difference in this case is that you would save the token in the desktop application instead of in the browser.
– Pagotti
For me the question is broad, but part of a possible answer is in this item: "For example, if my API does not have a token, as I would always send these credentials to this API, without the user having to intervene at each request?" - Simply put the token in the API :) However, you would not send the password open, so another exit would be to hash and save only it. But every exit along this path leads to the ability to copy credentials. The good thing is that each client application saves a token and a separate nonce
– Bacco