Autenticazione delle API degli aggiornamenti software

2

Abbiamo bisogno di migliorare un sistema che fornisca aggiornamenti software (file firmware / software) a un dispositivo Bluetooth attraverso un'applicazione "companion" installata sugli smartphone dei clienti (ios / android).

Il processo di aggiornamento è implementato attraverso chiamate a un server API REST (ASP.net, TLS 1.2) ed essendo "userless" (ma con app diverse) abbiamo utilizzato OAuth2 con il flusso "client_credentials", fino ad ora.

Abbiamo utilizzato la coppia "client_id" e "client_secret" per identificare l'applicazione del chiamante e quindi iniettare alcune attestazioni nel token al portatore, utile ad esempio per fornire firmware diversi a diverse applicazioni. Allo stesso tempo, abbiamo utilizzato questo sistema per prevenire richieste API non autorizzate.

Funziona, ma non ho mai amato questo sistema completamente per vari motivi, ad esempio:

  • Senza utenti, il server token non crea solo un sovraccarico?
  • L'archiviazione dell'ID client e del segreto (in testo non crittografato) nelle app mobili è sicuro?

Ho letto le chiavi API, ma come questo post dice che non sono abbastanza .

Penso che stiamo "estendendo" gli obiettivi di OAuth2 alle nostre esigenze, ci sono modi migliori per gestirlo?

    
posta iRubens 16.02.2017 - 09:41
fonte

1 risposta

1

Memorizzare il client_secret in testo semplice non è una buona idea, ios fa abilita la crittografia dei dati a riposo per impostazione predefinita ma per android devi lavorare da solo

Per quanto riguarda il modo in cui stai usando OAuth2, posso solo dire che funziona per il tuo caso d'uso. Forse questo articolo ti aiuterà a venire a patti con il tuo attuale set up, tra le parti importanti che afferma:

"...one of the key reasons for OAuth2 to exist is so that Client applications do not need to collect user credentials (as they did with Basic authentication).

The Client has to obtain an access token, and to do that it has to be pre-registered with the Authorization Server, and it has to authenticate itself at the token endpoint.

Quindi direi che, in base alla progettazione e in termini di sicurezza, dover richiedere il token è uno dei punti di forza di OAuth2.

Se stai cercando alternative per distribuire i tuoi aggiornamenti software, la mia opinione è che l'utilizzo degli app store predefiniti dovrebbe essere sufficiente. Un aggiornamento non deve essere il minimo numero di dati necessari per raggiungere l'obiettivo aziendale , può essere lo stesso pacchetto di prima con nuovi dati da utilizzare, ciò che intendo è che l'aggiornamento del software è l'applicazione wrapper che viene inviata all'app store e al momento dell'installazione tenta di trasferire i dati aggiornati (non necessariamente l'intera app) al dispositivo bluetooth.

    
risposta data 16.02.2017 - 12:02
fonte

Leggi altre domande sui tag