I cookie devono essere utilizzati in un'API RESTful?


78

Sono particolarmente interessato a come gli utenti eseguono operazioni autorizzate / autenticate su un'API Web.

I cookie di autenticazione sono compatibili con la filosofia REST e perché?


duplicato esatto di autenticazione riposante


1
@JarrodRoberson La mia comprensione era che le risposte su un altro sito non avrebbero potuto qualificare la domanda come duplicata qui
Tom Squires

5
@JarrodRoberson in base alle FAQ di ciascun sito, direi che la domanda appartiene a questo sito e non a StackTranslate.it. Sono interessato alla metodologia / filosofia di progettazione e ai compromessi su questo aspetto dell'architettura RESTful. Stack Overflow è pensato per domande di implementazione, in cui questo sito è maggiormente dedicato alle metodologie di progettazione e ai compromessi.
Brandon Linton,

1
Sono d'accordo con @BrandonLinton qui, la domanda è troppo ampia per StackOverflow, è una questione di architettura e metodologia di progettazione. L'OP vuole le migliori pratiche e modelli, suggerimenti e trucchi - non una risposta specifica - quindi non è stata specificata alcuna lingua. Quindi, appartiene qui.
dooburt,

Risposte:


81

Un servizio ReSTful ideale consente ai client (che potrebbero non essere nel browser) di eseguire qualsiasi attività necessaria in una richiesta ; perché lo stato completo necessario per farlo è gestito dal client, non dal server. Poiché il client ha il pieno controllo dello stato, può creare lo stato da solo (se ciò è legittimo) e parlare all'API solo per "completarlo".

Richiedere i cookie può renderlo difficile. Per i clienti oltre ai browser, la gestione dei cookie è un grosso inconveniente rispetto ai parametri di query, alle intestazioni di richiesta semplici o al corpo della richiesta. D'altra parte, nel browser, l'uso dei cookie può rendere molte cose molto più semplici.

Quindi un'API potrebbe prima cercare Authorizationnell'intestazione i dati di autenticazione di cui ha bisogno, poiché è probabilmente il luogo in cui i client non browser preferiranno metterli, ma per semplificare e semplificare i client basati su browser, potrebbe anche verificare la presenza di un cookie di sessione per l'accesso lato server, ma solo se Authorizationmancava l' intestazione normale .

Un altro esempio potrebbe essere una richiesta complessa che normalmente richiede un sacco di parametri impostati. Un client non interattivo non avrebbe problemi a inserire tutti quei dati in un'unica richiesta, ma un'interfaccia basata su moduli HTML potrebbe preferire suddividere la richiesta in più pagine (qualcosa come una serie di pagine 'wizard') in modo che gli utenti non vengano presentati con opzioni non applicabili in base alle selezioni precedenti. Tutte le pagine intermedie potrebbero memorizzare i valori nei cookie lato client, in modo che solo l'ultima pagina, in cui l'utente invia effettivamente la richiesta, abbia alcun effetto lato server. L'API potrebbe cercare gli attributi necessari nel corpo della richiesta e ricorrere ai cookie se i parametri necessari non fossero presenti.

Modifica: in RE al commento di @ Konrad qui sotto:

I token a confronto sono più difficili da implementare soprattutto perché non è possibile invalidare facilmente il token senza memorizzarli da qualche parte.

ehm ... stai convalidando i cookie sul lato server, giusto? Solo perché hai detto al browser di eliminare un cookie dopo 24 ore non significa che lo farà. Quel cookie potrebbe essere salvato da un utente altamente tecnico e riutilizzato molto tempo dopo che è "scaduto".

Se non si desidera archiviare i dati della sessione sul lato server, è necessario memorizzarli nel token (cookie o altro). Un token di autenticazione autonomo viene talvolta chiamato Amaretto. Il modo in cui questo viene passato tra client e server (sia tramite cookie, come intestazioni extra o nell'entità richiesta stessa) è totalmente indipendente dal meccanismo di autenticazione stesso.


4
+1, mi piace sicuramente la praticità di utilizzare l'intestazione dell'autorizzazione ma "ricadere" sui cookie a seconda di ciò che funziona meglio per il cliente.
Brandon Linton,

Non sono d'accordo con "Per i clienti oltre ai browser, la gestione dei cookie è un grosso inconveniente ...". Principalmente le librerie client HTTP supportano i cookie, ad esempio, con HttpClient.NET è possibile utilizzare i cookie senza alcun problema e non è necessario pensarci. I token a confronto sono più difficili da implementare soprattutto perché non è possibile invalidare facilmente il token senza memorizzarli da qualche parte.
Konrad,

1
@Konrad solo perché è facile in alcuni client non browser non significa che sia facile in tutti. Va bene se hai solo bisogno di supportare il client specifico che usi, ma ho interpretato la domanda sulle API pubbliche. in curlo wget, la gestione dei cookie è dannatamente scomoda e devi davvero pensarci un sacco. Ho risposto all'altro punto modificando la mia risposta.
SingleNegationElimination

Attenzione che accettare semplicemente i cookie apre le vulnerabilità del CSRF. Vedi anche security.stackexchange.com/a/166798
Michael Osl,

14

Sì e No - Dipende da come lo usi.

I cookie se utilizzati per mantenere lo stato del client sul client, per il client, del client e dal client, sono riposanti.

Se stai memorizzando lo stato del server nel cookie, in pratica stai semplicemente spostando il carico sul client, il che non è riposante.

Quindi quali sono alcuni esempi?

Riposante:

  • Dettagli di autenticazione o roba di tipo "login"
  • ultima pagina visualizzata o luogo nell'applicazione ecc.

Non riposante:

  • Memorizzazione delle informazioni sulla sessione

La tranquillità deriva dall'apolidia del server. I client possono mantenere lo stato dell'applicazione e inviarlo al server per dire dove si trovano in modo che il server possa decidere dove andare da lì. Fondamentalmente sessioni / stati hanno bisogno di dati storici e dipendono da richieste passate per così dire, idealmente le applicazioni riposanti non lo sono (Non è fattibile avere un'applicazione riposante pura al 100% se hai intenzione di avere una schermata di accesso :)


10
Se memorizzi un flag "isLoggedIn" sul client, potresti anche non utilizzare alcuna autenticazione.
martedì

Ciò ha sicuramente senso: la memorizzazione dello stato dell'applicazione sul lato client non sarebbe coerente con REST, ma le informazioni sul client che utilizza per rappresentare se stessa sembrano soddisfacenti.
Brandon Linton,

1
Vorrei aggiungere che l'inserimento di informazioni di autenticazione nei cookie lascia aperta la possibilità di attacchi di contraffazione di richieste tra siti. Ci sono modi migliori, suggerisco di copiare Amazon: docs.aws.amazon.com/AmazonS3/latest/API/…
Dobes Vandermeer

@tdammers che dire se il flag "isLoggedIn" si trova in un JWT? Quindi ciò dovrebbe essere sicuro, a condizione che il JWT sia emesso e verificato correttamente.
Aaron J Spetner,


12

Si possono usare i cookie. REST consente loro.

REST richiede che tutte le informazioni sulla sessione vengano archiviate sul lato client, ma quando si tratta di autenticazione, alcune informazioni devono rimanere sul lato server per motivi di sicurezza.

Da uno dei miei post sul blog , c'è un accordo generale sul fatto che i dati di autenticazione siano considerati fuori campo rispetto a REST. Quindi, è ok per i server mantenere alcuni dei dati di questa sessione dalla loro parte.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.