La best practice è:
L'idea di base. Crea una chiave API (una chiave simmetrica a 128 bit) per ogni account utente separato. Questa chiave deve essere archiviata in modo sicuro sul server e archiviata in modo sicuro sul client dell'utente.
Per ogni richiesta fatta dal cliente, aggiungi un parametro di richiesta extra che ha una "firma" sull'intera richiesta. La "firma" deve essere calcolata come S = MAC ( K , R ), dove K è la chiave API e R è l'intera richiesta, inclusi tutti i parametri di richiesta. Qui MAC dovrebbe essere un algoritmo di codice di autenticazione dei messaggi sicuro, come AES-CMAC o SHA1-HMAC.
È responsabilità del cliente calcolare la firma e aggiungerla alla richiesta; è responsabilità del server verificare la firma e ignorare qualsiasi richiesta con una firma non valida. Potrebbe anche essere necessario includere un parametro aggiuntivo con la richiesta che identifica l'account utente che effettua la richiesta.
Ciò fornirà l'autenticazione della richiesta, ma non la riservatezza o la prevenzione della riproduzione, e il client riceve una risposta autenticata dal server.
Suggerisco di inviare tutte le richieste tramite https (non http). Ciò fornirà un ulteriore livello di sicurezza contro una serie di casi complicati. Le implicazioni sul rendimento di ciò sono inferiori a quanto potresti pensare: SSL ha un sovraccarico di prestazioni inferiore rispetto alla maggior parte delle persone pensa - quindi non scartare questa idea per motivi di rendimento a meno che tu non abbia misurato sul sovraccarico delle prestazioni e trovato inaccettabile.
Altre cose a cui prestare attenzione. Potresti voler utilizzare un nonce utilizzabile una sola volta, per impedire la riproduzione delle richieste autenticate. Suggerisco di usare un valore casuale di forza crittografica (lungo almeno 64 bit). Questo non è necessario se stai usando https.
Assicurati che il tuo server sia scritto per difenderci da attacchi per l'inquinamento da parametri host (HPP) . Ad esempio, dovrebbe rifiutare qualsiasi richiesta con più parametri di richiesta dello stesso tipo (ad esempio http://example.com/foo.html?name=x&name=y ). Inoltre, quando scrivi il codice del server, fai attenzione quando crei nuove richieste in base a una richiesta che hai ricevuto. Ad esempio, prima di elaborare ogni richiesta, il codice del server potrebbe convalidare che la richiesta viene fornita con l'elenco di parametri previsto e nient'altro; eliminare i parametri duplicati o i parametri non previsti prima di elaborare la richiesta.
Fai attenzione ai difetti di concatenazione se decidi di proteggere più valori con il codice di autenticazione dei messaggi.