Il punto di differenza tra l'utilizzo dell'autenticazione HTTP e dell'autenticazione specifica dell'applicazione è il punto in cui si desidera gestire la logica di autenticazione e autorizzazione.
Autenticazione HTTP significa che il livello HTTP (apache, nginx, IIS, ecc.) sarà responsabile della gestione dell'autenticazione. Autorizzazione dell'applicazione significa che l'applicazione web (java, php, django, ecc.) Controllerebbe l'autenticazione e l'autorizzazione.
Perché la differenza?
Ricorda che HTTP è senza stato. Pertanto, aggiungendo un componente di autorizzazione, HTTP può impedire o consentire agli utenti di accedere a determinate risorse. L'uso più probabile di questo tipo di autorizzazione è quando non si dispone di alcuna logica dell'applicazione. Ad esempio, se si desidera consentire l'esplorazione della directory di file in apache, ma solo per determinati utenti, è possibile modificare il file .htaccess
per limitare la directory a determinati utenti.
Tuttavia ci sono molte ragioni per cui le applicazioni gestiscono la logica di autorizzazione invece del server HTTP. Innanzitutto, la maggior parte delle applicazioni gestisce le sessioni. Questo viene fatto usando i cookie. Pertanto, solo il valore del cookie deve essere ritrasmesso. Se gestisci sessioni nel livello applicazione, sarà quasi sempre più facile gestire l'autorizzazione anche in questo livello. Quasi sempre, le sessioni sono preferite perché il contenuto della tua applicazione dipenderà da "chi "sta facendo qualcosa.
Ma la mia applicazione può leggere le intestazioni HTTP, perché utilizzare i moduli se HTTP fornisce un meccanismo?
Un ulteriore vantaggio dell'utilizzo delle sessioni include l'implicita capacità di disconnessione. Poiché l'autorizzazione HTTP non ha alcun concetto di sessione, non puoi davvero effettuare il logout. Spetterebbe al browser (o nel tuo caso, l'applicazione Android) dimenticare le credenziali, ma il server non ha il controllo su di esso. Anche se il tuo server vuole imporre una sorta di disconnessione, non può farlo con l'autorizzazione HTTP.
Vantaggi per la sicurezza dell'autenticazione basata su modulo
Poiché l'autenticazione basata su modulo generalmente implica sessioni, di solito è più sicura, a condizione che la sicurezza delle risorse dipenda dalle sessioni.
Vantaggi per la sicurezza dell'autenticazione HTTP
L'autenticazione di base HTTP è peggiore dell'autenticazione basata su moduli a causa della mancanza di sessioni. Tuttavia, è possibile ottenere alcuni vantaggi utilizzando l'autenticazione HTTP Digest, che calcola gli hash contro le credenziali e gli spegni per evitare l'invio di credenziali di testo. Pertanto, esiste un compromesso tra l'invio di credenziali chiare o l'attivazione da parte del server dell'applicazione della sessione.
Non posso calcolare gli hash sul lato client prima di trasmettere le credenziali?
Per le applicazioni basate su browser, molte persone pensano che usare javascript per calcolare un hash prima di inviare una credenziale sia meglio che usare una password in testo semplice, ma queste persone hanno torto. Per proteggere la password, il server invia il codice client che deve essere eseguito. Tuttavia, se un utente malintenzionato è in grado di parlare con il cliente, può sostituire questo codice per conto suo. Pertanto, il vantaggio di sicurezza dell'utilizzo di javascript per calcolare un hash è così minimo che raramente viene eseguito.
Dato che hai menzionato l'utilizzo di questa API in un'applicazione Android, l'hashing ha senso. Poiché è possibile calcolare l'hash con una routine client predefinita, ci sono chiari vantaggi nell'utilizzo di un meccanismo di hashing come descritto in RFC 2607 . Ti consiglio comunque di eseguire l'autorizzazione nel livello dell'applicazione, poiché desideri gestire le sessioni per un utente.