Un buon approccio per uno schema di token API Web?

Question

Sto lavorando su un'API REST per un'applicazione web che fino ad ora abbiamo sviluppato internamente per un paio di applicazioni complementari. Ora che stiamo cercando di aprire agli sviluppatori esterni, vogliamo aggiungere token all'API per aiutare a identificare chi sta facendo richieste e in generale per aiutarlo a gestirlo. A questo punto utilizziamo https e l'autenticazione di base per l'autenticazione dell'utente sull'API.

Lo schema di token di cui stiamo discutendo sarebbe molto semplice dove a ogni sviluppatore verrebbero assegnati 1 o più token e questi token sarebbero passati come parametro per ogni richiesta.

La mia domanda è se hai fatto qualcosa di simile prima come hai fatto (hai fatto più o meno, come hai gestito la sicurezza, ecc.) E hai qualche consiglio?

Grazie!

Answer 1

In primo luogo, si potrebbe desiderare di guardare http://OAuth.net. A seconda dei tuoi casi d'uso, potrebbe fornire la sicurezza di cui hai bisogno.

Per quanto riguarda il token, è un BLOB per la maggior parte dei protocolli, incluso OAuth. Puoi inserire qualsiasi informazione di cui hai bisogno in qualsiasi formato.

Qui è quello che facciamo,

1. Per prima cosa assegnare ogni sviluppatore di una chiave segreta con associata.
2. Il token stesso è una coppia nome-valore crittografata. Inseriamo cose come username, scadenza, id di sessione, ruoli ecc. È crittografato con il nostro segreto in modo che nessun altro possa farcela.
3. Per semplificare l'utilizzo con l'API Web, utilizziamo la versione URL-safe di Base64 in modo che il token sia sempre sicuro per gli URL.

Spero che questo aiuti!

Answer 2

Si potrebbe anche decidere di aggiungere un token basato sull'ora che consenta di limitare la quantità di tempo in cui una richiesta è valida. questo aiuterà con qualcuno che sta cercando di fare un attacco di replay.

Si dovrebbe eseguire una chiamata di handshake per ottenere/assegnare un token valido in base al suddetto developerKey. Questo token verrebbe memorizzato localmente e restituito al chiamante.

Lo sviluppatore utilizzerà quindi questa chiave in una richiesta per convalidare la richiesta e lo sviluppatore.

Ad esempio, tale chiave può essere utilizzata per 5 minuti o per 10 richieste o qualsiasi altra definizione. dopo quel punto il token generato in base al tempo generato viene rimosso dall'elenco valido e non può più essere utilizzato. lo sviluppatore dovrà quindi richiedere un nuovo token.

Answer 3

UUID è molto buono per qualsiasi chiave casuale temporanea che desideri spendere. Imprevedibile e veloce da generare, con collisioni così improbabili che sono effettivamente uniche. Fai anche delle belle chiavi di sessione.