Come fanno l'app mobile e i servizi web a comunicare in modo sicuro?

Ci sono 3 modi di base per generare token e firma usati per autenticare le chiamate dall'app mobile ai servizi web.

1. OAuth Core 1.0a

Oauth 1.0a è il più sicuro dei tre protocolli comuni. Oauth1 è un protocollo ampiamente utilizzato, testato, sicuro e basato sulla firma. Il protocollo usa una firma crittografica (di solito HMAC-SHA1) che combina il segreto del token, il nonce e altre informazioni basate sulla richiesta. Il grande vantaggio di OAuth 1 è che non si passa mai direttamente il segreto del token attraverso il filo, il che elimina completamente la possibilità che qualcuno veda una password in transito. Questo è l'unico dei tre protocolli che può essere tranquillamente utilizzato senza SSL (anche se si dovrebbe comunque utilizzare SSL se i dati trasferiti sono sensibili). Tuttavia, questo livello di sicurezza ha un prezzo: generare e convalidare le firme può essere un processo complesso. Devi usare algoritmi di hashing specifici con una serie rigorosa di passaggi. Tuttavia, questa complessità spesso non è più un problema, dato che tutti i principali linguaggi di programmazione hanno una libreria che gestisce questo per voi.

2. Autenticazione di base con TLS

L'autenticazione di base è la più facile delle tre da implementare, perché la maggior parte delle volte, può essere implementata senza librerie aggiuntive. Tutto il necessario per implementare l'autenticazione di base è di solito incluso nel vostro framework standard o nella libreria del vostro linguaggio. Il problema con l'autenticazione di base è che è, beh, "di base", e offre le opzioni di sicurezza più basse dei protocolli comuni. Non ci sono opzioni avanzate per l'utilizzo di questo protocollo, quindi state semplicemente inviando un nome utente e una password che sono codificati in Base64. L'autenticazione di base non dovrebbe mai essere usata senza la crittografia TLS (precedentemente conosciuta come SSL) perché altrimenti la combinazione di nome utente e password può essere facilmente decodificata.

3. OAuth 2.0 - OAuth

Oauth2 sembra un'evoluzione di Oauth1, ma in realtà è una versione completamente diversa dell'autenticazione che cerca di ridurre la complessità. L'attuale specifica di Oauth2 rimuove le firme, quindi non è più necessario utilizzare algoritmi crittografici per creare, generare e convalidare le firme. Tutta la crittografia è ora gestita da TLS, che è richiesto. Non ci sono tante librerie Oauth2 quante ce ne sono di Oauth1a, quindi integrare questo protocollo nelle vostre API potrebbe essere più impegnativo. L'autore principale ed editore dello standard Oauth2 si è dimesso, con questo post informativo. A causa di questa instabilità nel comitato delle specifiche e perché le impostazioni predefinite di OAuth2 sono meno sicure di OAuth1 (nessuna firma digitale significa che non è possibile verificare se i contenuti sono stati manomessi prima o dopo il transito), raccomando OAuth1 su OAuth2 per applicazioni di dati sensibili. OAuth2 potrebbe avere senso per ambienti meno sensibili, come alcuni social network.

Naturalmente puoi sempre creare il tuo modo personalizzato per generare questo token e la firma per far comunicare la tua app in modo sicuro con il tuo servizio web. I protocolli di autenticazione personalizzati dovrebbero essere evitati a meno che non si sappia veramente, veramente cosa si sta facendo e si comprendano appieno tutte le complessità delle firme digitali crittografiche. La maggior parte delle organizzazioni non ha questa competenza, quindi raccomando OAuth1.0a come una solida alternativa.

Ovvero generare una API_KEY unica per ogni utente come quello che ha fatto la maggior parte dei servizi di terze parti (come mailgun).