Nel caso in cui i meccanismi di sicurezza propri del protocollo HTTP non siano sufficienti o adeguati per il tipo di Web Service da sviluppare, è sempre possibile gestire la sicurezza in modo personalizzato. In genere questo accade per la gestione dell'autenticazione e dell'autorizzazione dei client, dove i criteri possono essere diversi in base allo specifico dominio del problema.
Non c'è un obbligo nell'utilizzare i meccanismi standard del protocollo HTTP, ma è bene sottolineare che ogni eventuale soluzione personalizzata deve rispettare i principi REST.
Il rischio di cadere in una soluzione non-RESTful per gestire l'autenticazione e l'autorizzazione dei client è alto, dal momento che un istinto quasi involontario tenterebbe di re-introdurre il concetto di sessione associata al client appena autenticato.
In realtà il problema non sta nel concetto di sessione, ma nella modalità di gestione.
Dal momento che REST non ammette il mantenimento dello stato della sessione tra una richiesta e le altre, occorre che client e server si scambino tutta l'informazione necessaria per ricreare la sessione ad ogni interazione. Questo vuol dire rigenerare la sessione ad ogni richiesta utilizzando le credenziali fornite dal client, con potenziale perdita di prestazioni anche se i criteri di autenticazione ed autorizzazione non sono molto complessi.
Lo stato come risorsa
Un'alternativa potrebbe essere trasformare la sessione in risorsa. In pratica si tratta dello stesso approccio adottato per l'implementazione del carrello del nostro negozio online. L'autenticazione di un client corrisponde alla richiesta di creazione di una risorsa di tipo sessione: se le credenziali fornite dal client sono valide, allora viene creata la risorsa ed inviato il corrispondente l'URI al client, che da questo momento in poi invierà al server con ogni richiesta.
Ad ogni richiesta il server recupererà la sessione per effettuare le necessarie verifiche e in caso positivo soddisferà le richieste del client.
Il server avrà la responsabilità di gestire opportunamente la sessione, come ad esempio eliminarla dopo un determinato periodo di inattività, ma non la manterrà in memoria, la gestirà come una normale risorsa persistente.
OpenID e OAuth: gestione esterna della sicurezza
Putroppo la gestione dell'autenticazione e dell'autorizzazione dei client rischia di complicare la progettazione e l'implementazione di un Web Service. La soluzione ideale sarebbe di delegare ad un servizio esterno il compito di gestire i client: in pratica un Web Service specializzato nella gestione dell'autenticazione e/o dell'autorizzazione.
Negli ultimi tempi sono venuti alla ribalta servizi aperti che si pongono proprio questo obiettivo: decentralizzare la gestione di alcuni aspetti della sicurezza. Tra i servizi di questo tipo più noti e diffusi nell'ambito della realizzazione di Web Service RESTful ci sono OpenID e OAuth.
OpenID è un protocollo per la gestione dell'identità online. Esso consente ad un client di presentare ad un Web Service o ad un sito Web un URI come dichiarazione della propria identità. L'applicazione Web chiede conferma della validità al relativo servizio di autenticazione (OpenID provider) il quale, dopo aver interagito con il client, conferma o smentisce l'autenticità dell'identità dichiarata.
OAuth è un protocollo per la concessione a terze parti di autorizzazioni per l'accesso a risorse protette. In pratica, un client può consentire ad un Web Service l'accesso ad una risorsa protetta, ospitata da un service provider, senza fornire le proprie credenziali.
È naturale che l'utilizzo di servizi esterni per la gestione di alcuni aspetti della sicurezza presuppone che il Web Service riponga piena fiducia nel fornitore del servizio, senza la quale questo tipo di servizi non avrebbero senso.
