Autenticazione utente / password restful

Naviga le tue risposte
2

Attualmente sto progettando un REST-API con le seguenti proprietà:

  1. Backend per un'applicazione a singola pagina (Applicazioni successive)
  2. Database utente integrato per ogni istanza
  3. Solo HTTPS / TLS
  4. Autenticazione con una combinazione nome utente / password

Il mio approccio attuale per il processo di autenticazione è il seguente:

  • (Client) POST Username e password a /api/users/action/auth
  • (server) Autentica utente, genera token, invia token al client
  • (Cliente) Utilizza l'intestazione di autorizzazione con token per la richiesta successiva
  • (Cliente) DELETE /api/users/action/auth per invalidare il token

Il token scadrà dopo un certo periodo di inattività.

Ho scelto questo design perché non mi piace l'idea di archiviare i dati di autenticazione semplici sul dispositivo client.

Leggendo molte altre domande e articoli su questi argomenti, non penso che questo approccio sia il migliore. Sono sorte le seguenti domande:

  • La generazione e l'utilizzo di token per le richieste successive violano il principio stateless di REST?
  • Questa procedura è sicura? (XSRF?)
  • Esiste un approccio di progettazione migliore? Ho pensato che OAuth potrebbe essere un overkill

EDIT:

Riguardo a "sicuro":

L'applicazione conterrà molte informazioni sensibili, quindi la sicurezza è molto importante. Supponendo che l'uso sicuro di HTTPS (solo TLS, gruppo DH strong, nessuna mod di esportazione, ecc.) Ci siano problemi di sicurezza facili da utilizzare in questo approccio?

Riguardo a "migliore":

Ho scelto questo modello perché è facile da implementare su entrambi i lati. Ho pensato di usare HMAC(token, 'POST' || '/api/resource' || timeInterval) come token per ogni richiesta, la mia conclusione è stata che ciò avrebbe aggiunto complessità inutili senza migliorare la sicurezza. (Già usando TLS)

    
posta Frido 19.08.2015 - 11:17
fonte

2 risposte

7

L'apolidia di REST si riferisce al lato del server. Se passi il tuo token in ogni richiesta, questo diventa parte dello stato che viene inviato dal client e quindi non viola l'apolidia del tuo server.

Ciò differisce, ad esempio, dalla gestione dello stato sul server in cui vengono mantenute le informazioni nella sessione sul lato server. Un ID di sessione inviato insieme alla richiesta e associato alle informazioni sul server interrompe l'apolidia in quanto il server web mantiene uno stato.

Per quanto riguarda "meglio" e "sicuro", non esiste una risposta definitiva a questa domanda. La domanda è: che tipo di sicurezza hai bisogno, cosa vuoi e quanto lontano sei disposto ad implementarlo.

    
risposta data 19.08.2015 - 12:09
fonte
1

Prima di tutto, non mettere REST sopra a risolvere i problemi in modo efficiente. Affinché i client possano accedere, è necessario memorizzare in qualche modo alcuni stati. Che tu non consideri questo contro il mantra REST non importa, devi comunque farlo.

È possibile creare token con firma digitale contenenti tutte le informazioni di sessione e non memorizzarli sul server. Ma per la maggior parte degli scopi questo non raggiunge nulla di pratico.

Suppongo che tu memorizzi il token nella memoria JavaScript sul client, invialo come un'intestazione speciale ad ogni richiesta e restituisca solo i dati sensibili o cambi i dati quando il token corretto è impostato in quell'intestazione. In tal caso dovresti essere al sicuro da XSRF, questi buchi in genere si verificano solo quando si utilizzano i cookie.

C'è un design migliore? Probabilmente, ma data la tua descrizione, la tua è probabilmente abbastanza buona.

    
risposta data 19.08.2015 - 12:21
fonte

Leggi altre domande sui tag

L'uso del prefisso set / get è scoraggiato per i metodi se in realtà non mutano / accedono ai campi Prova il dilemma Catch and Flow Control