API RESTful con token di sessione .. ehh?

Question

API RESTful con token di sessione .. ehh?

#1 da (5 voti)
#2 da (-1 voti)

5

Dopo aver esaminato molti dibattiti di sessione / stato riguardo a REST e non trovando nulla di concreto, mi limiterò a inseguire e a chiedermi.

Sviluppando un'API RESTful come back-end per un'app mobile, io (penso io) voglio tenere traccia di tutti gli utenti (anche quelli non registrati) con le sessioni guest . Questo mi consente di personalizzare i contenuti e fare statistiche sui miei utenti.

Per quanto riguarda l'implementazione, vorrei che la mia app si identificasse come se si trattasse di un endpoint / autenticate, solo senza e-mail / password, più come UUID. Ma questo fa sì che tutta la mia API si aspetti un "token di sessione" con ogni richiesta.

È un approccio sbagliato o faresti lo stesso?

api rest authentication session app

posta Zoon 09.01.2017 - 17:21

fonte

2 risposte

-1

Perché questo approccio non sembra una buona idea?

Ragioni di sicurezza: la creazione del proprio "token di sessione" comporta elevati rischi di vulnerabilità. Un esempio che mi viene in mente qui è il dirottamento di token (ad esempio sul dispositivo, anche se il canale di comunicazione sarebbe protetto TLS).
Comunque, concettualmente, questo non si adatta all'architettura: il tuo token conterrà un numero univoco che dovrai tracciare sul lato del servizio. Ciò significa che il servizio ha uno stato (ad es. UUID attivo). Ma nella tua domanda vuoi il servizio RESTful , che significa senza stato.
In alternativa è possibile evitare lo stato sul server memorizzandolo nel token (ad esempio, l'UUID, un'ulteriore informazione combinata con l'UUID consente di valutare che l'UUID è valido e l'id utente). Ma poi esponi te stesso alla falsificazione del tuo token (ad es. Accedi per ottenere un UUID + appropriato quindi sovrascrivi l'id utente con un ID che ha più privilegi).

Migliore alternativa

Al fine di evitare di implementare un nido di vulnerabilità, utilizzare solo protocolli standardizzati e collaudati. Ad esempio, invece di reinventare il tuo token, utilizza il JWT comprovato che è protetto crittograficamente.

Letture aggiuntive:

risposta data 09.01.2017 - 19:15

fonte

Leggi altre domande sui tag api rest authentication session app

Le funzioni del client devono essere incluse nel diagramma UML di un progetto che utilizza sia la programmazione orientata agli oggetti che quella procedurale? Faking - Dipendenza vs dettagli interni

score 5 · Accepted Answer

L'approccio abituale consiste nel fornire semplicemente un token di sessione al client tramite intestazioni o cookie se non sono riusciti a fornirne uno o ne hanno fornito uno non valido. Ciò è particolarmente necessario per i client Web in cui la sessione può scadere mentre sono su una pagina da qualche parte. Questo ti assicura di avere la tua sessione immediatamente, senza andare al punto di "autenticazione", che dovrebbe fare ciò che suggerisce il nome: autentica l'utente.

Ovviamente, ciò significa che il client deve essere progettato per aspettarsi che il token di sessione cambi, ma questa è una cosa buona . La rigenerazione del token di sessione, in particolare sulle modifiche dei privilegi (ad esempio, passando da guest a utente completo), aiuta a prevenire il dirottamento di sessione. E non pensare che solo perché sei un'app mobile al posto di una pagina web sei al sicuro dal dirottamento. Non lo sei, un hacker può utilizzare Fiddler o qualche altro proxy per intercettare la tua API mobile.