Browser client, Node Server, struttura di autenticazione API Web

3

Ho un'API Web che accetta Authorization di intestazioni per consentire l'accesso. Risponde ai dati richiesti oltre ad impostare un cookie di sessione. Le richieste successive possono essere fatte senza intestazioni auth in quanto il cookie viene utilizzato al suo posto.

Originariamente, nessuna autenticazione veniva gestita sul server nodo. Le richieste API sono state fatte direttamente dal browser. Ciò ha reso semplice l'autenticazione, poiché il client inserito utente / pass è stato inviato direttamente nelle intestazioni e ha ricevuto un cookie di sessione in risposta.

Ora, tuttavia, vorremmo passare al rendering del payload iniziale sul server. Ciò richiederà sia il server sia il client essere "autorizzati" con l'API Web. Quali sono alcuni approcci comuni per farlo?

Un paio di possibilità che mi sono venute in mente:

  • Autent client con API come prima, l'API imposta cookie per future richieste browser, cookie client cookie su server nodo (che memorizza in sessione) per l'utilizzo in future richieste server.
  • Il client invia l'utente / passa al server nodo, l'autenticazione del nodo server e memorizza il cookie in sessione, tutte le successive chiamate API vengono eseguite tramite il server del nodo.
  • Il client invia normalmente l'utente / passa al server nodo, le autorizzazioni client normalmente, l'autenticazione del nodo server normalmente.

La prima opzione sembra ideale (se possibile). Questo è il modo in cui immagino che si utilizzi un "token di accesso". È possibile utilizzare cookie come questo? Esistono restrizioni di origine incrociata relative ai cookie che sto trascurando? Ad esempio, so che questo non funziona nel modo opposto (non posso eseguire l'autenticazione sul server, inserire cookie API in risposta al browser e fare in modo che il client utilizzi quel cookie per un percorso diverso (la web API invece del server nodo) .

Seconda opzione Desidero davvero evitare perché sembra che ci sia un sacco di traffico non necessario sul server dei nodi, molti percorsi standard e la nostra API Web è già molto semplice da utilizzare direttamente dal browser. Per quanto riguarda le prestazioni, questo aggiunge anche un ulteriore stop. Idealmente, il server dei nodi dovrebbe servire le richieste di pagina e questo è tutto.

La terza opzione sembra semplicemente una sciocchezza. Ne consegue che lo stesso utente viene autenticato in più punti, a cui l'API Web può piacere o meno (non l'ho progettato né conosco il suo funzionamento interno). Stiamo anche inviando due volte la password del nome utente sul filo (che sembra logicamente meno sicura di una volta).

Qualsiasi altro suggerimento è benvenuto!

    
posta thedarklord47 26.01.2016 - 03:16
fonte

0 risposte

Leggi altre domande sui tag