2013-06-30 12 views
10

Negli ultimi due giorni mi sono cimentato con una semplice idea di applicazione mentre cerco di insegnare a me stesso le basi dell'autenticazione REST.Autenticazione REST e chiave privata/HMAC (quando la imposto?)

Finora ho capito che il modo migliore per fare questo è con un'implementazione di HMAC come quella usata da Amazon.

La mia più grande preoccupazione è esattamente come suppongo di autenticare l'utente e dare loro la propria chiave privata in modo che possano iniziare a firmare l'HMAC? Continuo a leggere che la chiave privata utilizzata per firmare l'HMAC non dovrebbe essere inviata tramite il filo mai, ma come mai la ottengono in primo luogo?

La mia idea era qualcosa del genere, ma non sono sicuro se questo è valido.

tabella del database per gli utenti:

users (simplified, this would probably be a private key per client app?) 
    id (their public key?) 
    username 
    password? 
    privatekey 

Ipotizzando un HTML/client JS l'utente sarebbe presentato con una pagina di accesso tradizionale che post per l'API con qualcosa di simile:

https://example.com/myapp/api/v1/authenticate.json 
POST: username/password 

Quello restituire sia

404:User not found 
200:{ "id" : <id>, "privatekey": <privatekey> } 

Il client dovrebbe quindi memorizzare quella chiave da qualche parte (wou ld locali di stoccaggio/biscotto essere un luogo sicuro?) e usarlo per firmare ulteriori richieste che sarebbe simile a questa

GET https://example.com/myapp/api/v1/something/?key1=value1&publickey={theirID}&hmac={hmac signature of the request using their private key} 

Il server quindi controllare la chiave pubblica, recuperare la chiave privata associata e ricostruire la firma HMAC, se corrispondono corrispondono a una richiesta autenticata.

Ho capito bene? Non sono sicuro di capire il ruolo di una chiave privata se ho ancora bisogno di una password come nel mio esempio, quindi qualcosa mi sta dicendo che potrei sbagliarmi.

risposta

11

Penso che sia necessario fornire maggiori dettagli sulla propria applicazione e su come verrà utilizzata. Esistono molti modi per eseguire l'autenticazione REST. Alcuni di loro sono standard, altri no. Questi sono solo alcuni esempi:

  1. Basic authentication over SSL
  2. Digest authentication
  3. Vari tipi di token di autenticazione (OAuth 2, SPNEGO, vari STS)
  4. HMAC
  5. client certificati SSL
  6. Firmato/criptati biscotti.

In caso di Amazon S3, ti danno la "chiave di accesso segreto AWS" quando ti registri. Più tardi il codice dell'applicazione deve conoscere la chiave segreta per essere in grado di calcolare le firme (o è necessario conoscere la richiesta/URL firmati) Quindi, in definitiva, "chiave di accesso segreta" viene trasmessa sul filo almeno una volta inizialmente durante la registrazione.

Se si utilizza la crittografia a chiave pubblica (come i certificati client SSL) - si può evitare di trasmettere la chiave privata del tutto

  1. si genera la chiave pubblica/privata su client
  2. Invia chiave pubblica al server (o il certificato firmato dall'autorità fidata)
  3. Le richieste di segno (o nonces) con chiave privata e server convalidano la firma utilizzando la chiave pubblica.

Se il tuo obiettivo è quello di autenticare le richieste AJAX fatte sul tuo sito dopo che l'utente si è autenticato sulla pagina di accesso - puoi semplicemente usare i cookie firmati dal server.

+0

L'API non è altro che un mio piccolo progetto per insegnarmi qualcosa di nuovo. In questo senso stavo per costruire l'API prima e poi costruire il frontend come se fossi un estraneo. Invece di avere una chiamata diretta, usavo solo la mia API e mi chiedevo di usare l'autenticazione, in questo modo il mio frontend stava semplicemente consumando la mia API. Quando dici che Amazon S3 ti fornisce la chiave privata al momento della registrazione, penso che sia quello di cui non ero sicuro, quando lo do a una terza parte (o, in questo caso, lo do a me stesso). OAuth 2 sembra altrettanto promettente ... – jfrobishow

+0

Ho un dubbio. Se il client è un'applicazione web accessibile esternamente, la chiave segreta (memorizzata localmente o nei cookie) può essere visualizzata dal file JS sottostante visualizzando la sorgente. Destra? Come può essere prevenuto qualcosa del genere? –

Problemi correlati