Come creare token utente e dove archiviarlo (lato server)

3

Sto costruendo un'applicazione per iPhone e non voglio che l'utente debba registrarsi ogni volta che apre l'app, quindi voglio usare i token dell'utente. La mia domanda è c'è un modo comunemente accettato per creare token utente? Inoltre, memorizzo il token nel database accanto al nome utente / password / email, creo un nuovo database solo per contenere i token o semplicemente leggo il token quando arriva la richiesta HTTPS e dichiaro se proviene da me o non? Grazie!

Modifica: Ho intenzione di utilizzare JWT per gestire l'autenticazione, ma grazie per l'input!

    
posta Bryt12 16.09.2016 - 22:11
fonte

2 risposte

2

Questi token utente che ti servono hanno un suono simile ai cookie; -)

La gestione dei cookie è un problema spinoso e ci sono diversi approcci.

Un solito è una semplice stringa casuale di caratteri. L'utente lo mantiene e lo si convalida con un hash nel proprio database. Perdere questa stringa sarebbe davvero pessimo, fai attenzione.

Esiste una variazione comune di questa: invece di una stringa casuale codificare l'id utente e altri dati di sessione e firmarla (crittograficamente), quando l'utente la presenta, convalida la firma e utilizza i dati dal cookie stesso. Questo ti fa risparmiare un viaggio nel database.

Uno dei miei preferiti per i client nativi: token HMAC. Condividi una chiave segreta con il cliente. Il client utilizza questa chiave per hash un nonce e un timestamp e invia l'hash, il nonce e il timestamp al server. Il server esegue gli stessi calcoli per convalidare il valore ricevuto dal client.

In questo modo il segreto viene inviato sul filo una sola volta, riducendo il rischio di perdite. Ben implementato riduce anche il rischio di attacchi di replay.

Ce ne sono altri. Forse il tuo framework ne supporta già uno, in tal caso potresti farne meglio.

Valuta le diverse alternative e se hai bisogno di aiuto decidendo di contattarci.

    
risposta data 17.09.2016 - 02:49
fonte
1

Le parole magiche che vuoi guardare sono OAuth2 e / o OpenID - OpenID è davvero quello che stai cercando, dato che è l'autenticazione (chi è questo utente) focalizzata, piuttosto che l'autorizzazione (cosa può fare questo utente) focalizzata come è OAuth. Molte persone usano OAuth per l'autenticazione (chiedendo al provider OAuth un indirizzo email, ad esempio, e usando quello). Entrambi funzionano fornendo un token back, con scadenza appropriata e così via.

Usando uno standard, improvvisamente hai un'opzione davvero buona: perché tenere traccia degli utenti, delle password e di te stesso? È difficile da fare in modo sicuro, ti rende un bersaglio, aggiunge molte funzionalità di cui hai bisogno - scadenza, blocco, reset. Perché non saltare tutto questo e basta usare un provider OpenID / OAuth come Facebook, Twitter o Google? Questo è tutto ciò che accedi a Facebook con le cose che vedi nelle app: semplifica la vita di tutti. Gli utenti non devono creare un'altra stupida password e non devi preoccuparti di memorizzarla.

Se non vuoi farlo (per qualche motivo) puoi ancora sfruttare gli standard - basta rendere il tuo server un provider di identità OpenID e utilizzare il loro schema per token, ecc.

    
risposta data 16.09.2016 - 22:39
fonte

Leggi altre domande sui tag