Impedisci a un'applicazione client desktop di abusare di un token di accesso API ottenuto tramite OAuth2 per conto di un'applicazione

Ho il seguente caso d'uso:

• Voglio scrivere un'applicazione desktop che faccia uso di un'API di terze parti (ad esempio Dropbox)
• Questa API richiede un access_token da inviare al server con ogni richiesta.
• Questo token viene generato per conto dell'utente e della mia applicazione utilizzando un flusso di autenticazione OAuth2 , che l'utente esegue sul mio sito Web.

Ora, normalmente passerei il access_token generato all'applicazione desktop, dove può essere utilizzato per effettuare chiamate all'API. Tuttavia, poiché access_token è memorizzato sul computer dell'utente, sarebbe in grado di estrarre e abusarne per scopi non previsti dall'applicazione (ad esempio, superando il limite di velocità dell'API o eseguendo richieste malevoli).

Per risolvere questo problema, potrei ovviamente eseguire il tunneling di tutto il traffico dell'API attraverso il mio back-end del server e quindi evitare di fornire all'utente il access_token . Tuttavia, ciò comporterebbe un notevole costo aggiuntivo e rappresenterebbe un rischio per la sicurezza del client poiché i suoi dati passerebbero attraverso un ulteriore servizio di terze parti prima di passare al server API.

C'è un altro modo per impedire al client di recuperare il access_token , pur continuando a consentirgli di usarlo per fare richieste al server API?

Ho letto sul passaggio della connessione TCP, che mi permetterebbe di creare una connessione al server API sul mio back-end usando il token di accesso e quindi passare quella connessione al client, ma questa tecnica sembra piuttosto sperimentale e probabilmente non è pronto per la produzione.

Un altro modo sarebbe utilizzare la crittografia asimmetrica per cifrare in qualche modo il access_token insieme con l' URL sul server back-end e lasciare che il client trasferisca questi dati pre-crittografati al server API, ma di nuovo Non ho idea di come implementarlo usando SSL.

Qualche idea?

Modifica:

Ho pensato al problema e penso di avere una soluzione, che però richiederebbe un nuovo endpoint dell'API e quindi non risolverei il problema iniziale:

link