Suppongo che il "token", in questo caso solo deve essere sia un criptato stringa che il cliente può decifrare o qualche stringa casuale che viene memorizzata da qualche parte (ad esempio un database) che il cliente può quindi verificare, ma non sono proprio sicuro di cosa sia il client che si supponga faccia del token o perché è addirittura necessario un token - non è sufficiente un ID utente semplice ?
No, il token è un "biglietto da corsa". Proprio come un token della metropolitana. Il cliente lo presenta al gatekeeper quando richiede il servizio. In questo caso il provider esegue la propria autenticazione, quindi il client presenta il token al provider. In alcuni casi il provider potrebbe delegare l'autenticazione, ad esempio in the STS model, nel qual caso il provider potrebbe consegnare il token a terzi per l'autenticazione e persino l'autorizzazione.
Dal punto di vista del servizio, questo token deve:
- hanno un "shelf life". Altrimenti, il token sarebbe infinitamente riutilizzabile. Quindi, sul lato server, è possibile memorizzare il token in un negozio basato sulla sessione, dove si otterrà il timeout gratuitamente. Oppure puoi costruire una semplice tabella hash con scadenza.
- essere associati esclusivamente al titolare. In molti casi il provider utilizza qui un'approssimazione e afferma che il token può essere utilizzato solo dall'indirizzo IP richiedente originale.
Quindi al passaggio 3, il provider deve controllare nome utente e password. Se ciò si verifica, quindi creare un token (hash), che fa riferimento a una voce in un dizionario o Hashtable. Gli oggetti in Hashtable sono strutture contenenti il nome utente, l'indirizzo IP, probabilmente il tempo di emissione originale, forse i ruoli associati al nome utente e qualsiasi altra cosa si desidera memorizzare. Il fornitore di servizi rimanda questo token - l'hash, non la struttura - al client, tipicamente come un Set-Cookie. Quando il client restituisce il token (come cookie) sulle richieste successive, il provider controlla il dizionario per vedere se il token è disponibile, non ha scaduto, corrisponde all'indirizzo IP richiedente, è autorizzato per la risorsa richiesta, ecc. Se tutto è ok, onora la richiesta.
EDIT 2013 Giugno
Sono passati diversi anni ormai, e questa risposta è ancora ricevendo voti. Suggerirei che le persone guardino il token OAuth 2.0 Framework e i token Bearer.
Fondamentalmente fanno solo ciò che è descritto qui.
Se si vuole una buona implementazione esempio, si può guardare Apigee's Usergrid. Funziona in questo modo:
utente si autentica
POST https://api.usergrid.com/token -d '{"username":"Joe","password":"Sec4et!","grant_type" : "password"}'
utente riceve un access_token in risposta
L'utente effettua chiamate successive con l'intestazione Authorization: Bearer XXXXXXXXXX w qui XXXXX viene sostituito con il token al portatore. Questo token ha un time-to-live impostato dal server usergrid.
Uno dei presupposti è che si presume che chiunque abbia un token sia chi dice di essere. C'è un modo consigliato per renderlo più sicuro? –
Un getcha che ho trovato è un utente che cambia tra più indirizzi IP per richieste diverse, quindi l'originale e le richieste successive provenivano da diversi IP. http://serverfault.com/questions/470931/user-http-requests-coming-from-multiple-ip-adresses – dan
come afferma wikipedia - OAuth 2.0 non è sicuro: "OAuth 2.0 non supporta la firma, la crittografia, il binding del canale o la verifica del client. Fa affidamento completamente su SSL per un certo grado di riservatezza e autenticazione del server. [14] [15] OAuth 2.0 ha avuto numerosi livelli di sicurezza difetti esposti nelle implementazioni. [16] Il protocollo stesso è stato descritto come intrinsecamente insicuro dagli esperti di sicurezza e un contributore principale alle specifiche ha dichiarato che gli errori di implementazione sono quasi inevitabili. [17] [18] "Quindi dovremmo davvero usarlo? http://en.wikipedia.org/wiki/OAuth –