Come gestire l'autenticazione in un'architettura Client-Server RESTful è una questione di dibattito.
Comunemente, può essere raggiunto, nel mondo SOA su HTTP tramite:
- Autenticazione HTTP di base su HTTPS;
- Cookie e gestione delle sessioni;
- Token nelle intestazioni HTTP (ad es. OAuth 2.0 + JWT);
- Autenticazione della query con parametri di firma aggiuntivi.
Dovrai adattare, o ancor meglio mescolare quelle tecniche, per abbinare al meglio la tua architettura software.
Ogni schema di autenticazione ha i propri PRO e CON, a seconda dello scopo della politica di sicurezza e dell'architettura software.
Autenticazione HTTP di base su HTTPS
Questa prima soluzione, basata sul protocollo HTTPS standard, è utilizzata dalla maggior parte dei servizi web.
GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
È facile da implementare, disponibile per impostazione predefinita su tutti i browser, ma presenta alcuni inconvenienti noti, come la terribile finestra di autenticazione visualizzata sul browser, che persisterà (non esiste una funzione simile a LogOut qui), un consumo aggiuntivo di CPU sul lato server, e il fatto che il nome utente e la password siano trasmessi (tramite HTTPS) al Server (dovrebbe essere più sicuro lasciare che la password rimanga solo sul lato client, durante l'immissione da tastiera, e sia memorizzata come hash sicuro sul Server) .
Potremmo utilizzare l' autenticazione Digest , ma richiede anche HTTPS, poiché è vulnerabile agli attacchi MiM o Replay ed è specifico per HTTP.
Sessione tramite cookie
Ad essere onesti, una sessione gestita sul Server non è veramente Stateless.
Una possibilità potrebbe essere quella di conservare tutti i dati all'interno del contenuto dei cookie. E, in base alla progettazione, il cookie viene gestito sul lato server (il client, infatti, non tenta nemmeno di interpretare questi dati sui cookie: li restituisce al server solo ad ogni richiesta successiva). Ma questi dati sui cookie sono dati sullo stato dell'applicazione, quindi il client dovrebbe gestirli, non il server, in un puro mondo Stateless.
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
La stessa tecnica dei cookie è collegata a HTTP, quindi non è veramente RESTful, che dovrebbe essere indipendente dal protocollo, IMHO. È vulnerabile agli attacchi MiM o Replay .
Concesso tramite token (OAuth2)
Un'alternativa è inserire un token nelle intestazioni HTTP in modo che la richiesta sia autenticata. Questo è ciò che fa OAuth 2.0, ad esempio. Vedi RFC 6749 :
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
In breve, questo è molto simile a un cookie e presenta gli stessi problemi: non apolidi, basandosi sui dettagli di trasmissione HTTP e soggetti a molte debolezze di sicurezza - tra cui MiM e Replay - quindi deve essere utilizzato solo su HTTPS. In genere, un JWT viene utilizzato come token.
Autenticazione query
L'autenticazione della query consiste nel firmare ogni richiesta RESTful tramite alcuni parametri aggiuntivi sull'URI. Vedi questo articolo di riferimento .
È stato definito come tale in questo articolo:
Tutte le query REST devono essere autenticate firmando i parametri della query ordinati in minuscolo, in ordine alfabetico utilizzando la credenziale privata come token di firma. La firma dovrebbe avvenire prima dell'URL che codifica la stringa di query.
Questa tecnica è forse la più compatibile con un'architettura Stateless e può anche essere implementata con una gestione delle sessioni leggere (utilizzando sessioni in memoria invece della persistenza del DB).
Ad esempio, ecco un esempio di URI generico dal link sopra:
GET /object?apiKey=Qwerty2010
dovrebbe essere trasmesso come tale:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
La stringa che viene firmata è /object?apikey=Qwerty2010×tamp=1261496500e la firma è l'hash SHA256 di quella stringa utilizzando il componente privato della chiave API.
La memorizzazione nella cache dei dati lato server può essere sempre disponibile. Ad esempio, nel nostro framework, memorizziamo nella cache le risposte a livello di SQL, non a livello di URI. Quindi l'aggiunta di questo parametro extra non rompe il meccanismo della cache.
Vedi questo articolo per alcuni dettagli sull'autenticazione RESTful nel nostro framework client / server ORM / SOA / MVC, basato su JSON e REST. Poiché consentiamo la comunicazione non solo su HTTP / 1.1, ma anche su pipe o messaggi GDI (localmente), abbiamo cercato di implementare un modello di autenticazione RESTful e non fare affidamento sulla specificità HTTP (come intestazione o cookie).
Nota successiva : l'aggiunta di una firma nell'URI può essere vista come una cattiva pratica (poiché ad esempio verrà visualizzata nei registri del server http), quindi deve essere mitigata, ad esempio da un TTL appropriato per evitare replay. Ma se i tuoi registri http sono compromessi, avrai sicuramente maggiori problemi di sicurezza.
In pratica, la prossima autenticazione di token MAC per OAuth 2.0 potrebbe essere un enorme miglioramento rispetto allo schema attuale "Concesso da token". Ma questo è ancora un lavoro in corso ed è legato alla trasmissione HTTP.
Conclusione
Vale la pena concludere che REST non è solo basato su HTTP, anche se, in pratica, è anche principalmente implementato su HTTP. REST può usare altri livelli di comunicazione. Quindi un'autenticazione RESTful non è solo un sinonimo di autenticazione HTTP, qualunque sia la risposta di Google. Non dovrebbe nemmeno usare affatto il meccanismo HTTP ma deve essere estratto dal livello di comunicazione. E se usi la comunicazione HTTP, grazie all'iniziativa Let's Encrypt non c'è motivo di non utilizzare il corretto HTTPS, necessario in aggiunta a qualsiasi schema di autenticazione.