Domanda Autenticazione, autorizzazione e gestione delle sessioni in applicazioni Web e API tradizionali


Correggimi se ho torto: in un'applicazione web tradizionale, il browser aggiunge automaticamente le informazioni di sessione a una richiesta al server, in modo che il server possa sapere da chi proviene la richiesta. Cosa viene effettivamente aggiunto in realtà?

Tuttavia, in un'applicazione basata su API, questa informazione non viene inviata automaticamente, quindi quando si sviluppa un'API, devo verificare se la richiesta proviene da un utente autenticato, ad esempio? Come si fa normalmente?


60
2018-06-09 10:12


origine


risposte:


Il protocollo HTTP è stateless per impostazione, ogni richiesta viene eseguita separatamente e viene eseguita in un contesto separato.

L'idea alla base della gestione delle sessioni è quella di inserire le richieste dallo stesso client nello stesso contesto. Questo viene fatto emettendo un identificatore dal server e inviandolo al client, quindi il client salverebbe questo identificatore e lo rinvierà nelle richieste successive in modo che il server possa identificarlo.

Biscotti

In un tipico caso di browser server; il browser gestisce un elenco di coppie chiave / valore, note come cookie, per ciascun dominio:

  • I cookie possono essere gestiti dal server (creato / modificato / cancellato) utilizzando il Set-Cookie Intestazione di risposta HTTP
  • I cookie sono accessibili dal server (leggi) analizzando il Cookie Intestazione della richiesta HTTP.

I linguaggi / i framework di programmazione mirati al Web forniscono funzioni per gestire i cookie a un livello superiore, ad esempio, fornisce PHP setcookie/$_COOKIE scrivere / leggere i cookie.

sessioni

Torna alle sessioni In un tipico caso server-browser (di nuovo), la gestione delle sessioni lato server sfrutta la gestione dei cookie lato client. Gestione delle sessioni di PHP imposta un cookie id di sessione e lo usa per identificare le richieste successive.

API delle applicazioni Web?

Ora torna alla tua domanda; dal momento che tu sarai il responsabile della progettazione dell'API e della sua documentazione, l'implementazione sarebbe la tua decisione. Fondamentalmente devi

  1. dare al cliente un identificatore, sia tramite a Set-Cookie Intestazione della risposta HTTP, all'interno del corpo della risposta (risposta all'autenticazione XML / JSON).
  2. avere un meccanismo per mantenere l'identificatore / associazione del cliente. ad esempio una tabella di database che associa l'identificatore 00112233445566778899aabbccddeeff con client / utente #1337.
  3. fare in modo che il client rinvii l'identificatore inviato a (1.) in tutte le richieste successive, sia esso in un HTTP Cookie intestazione della richiesta, a ?sid=00112233445566778899aabbccddeeff param (*).
  4. cercare l'identificatore ricevuto, utilizzando il meccanismo in (2), verificare se un'autenticazione valida ed è autorizzato a eseguire l'operazione richiesta, quindi procedere con l'operazione per conto dell'utente auth.

Ovviamente puoi costruire sull'infrastruttura esistente, puoi usare la gestione delle sessioni di PHP (che si occuperà dell'1 / 2 e la parte di autenticazione di 4.) nella tua app, e richiedere che l'implementazione lato client faccia la gestione dei cookie (che si prenderà cura di 3.), e poi farai il resto della tua logica app su questo.


(*) Ogni approccio ha vantaggi e svantaggi, ad esempio, l'utilizzo di un parametro di richiesta GET è più semplice da implementare, ma può avere implicazioni sulla sicurezza, poiché le richieste GET vengono registrate. Dovresti usare https per applicazioni critiche (tutte?).


106
2018-06-27 23:48



La gestione della sessione è responsabilità del server. Quando viene creata una sessione, un token di sessione viene generato e inviato al client (e memorizzato in un cookie). Dopodiché, nelle richieste successive tra client e server, il client invia il token (solitamente) come cookie HTTP. Tutti i dati di sessione sono memorizzati sul server, il client memorizza solo il token. Ad esempio, per avviare una sessione in PHP devi solo:

session_start();  // Will create a cookie named PHPSESSID with the session token

Dopo aver creato la sessione, è possibile salvare i dati su di essa. Ad esempio, se si desidera mantenere un utente registrato:

// If username and password match, you can just save the user id on the session
$_SESSION['userID'] = 123;

Ora sei in grado di verificare se un utente è autenticato o meno:

if ($_SESSION['userID'])
    echo 'user is authenticated';
else
    echo 'user isn't authenticated';       

Se lo desideri, puoi creare una sessione solo per un utente autenticato:

if (verifyAccountInformation($user,$pass)){ // Check user credentials
    // Will create a cookie named PHPSESSID with the session token
    session_start();
    $_SESSION['userID'] = 123;
}

39
2018-06-23 18:54



Esistono numerosi modi per gli utenti autentici, sia per le applicazioni Web che per le API. Ci sono un paio di standard, oppure puoi scrivere la tua autorizzazione / e / o autenticazione personalizzata. Vorrei sottolineare la differenza tra autorizzazione e autenticazione. Innanzitutto, l'applicazione deve autenticare l'utente (o il client API) da cui proviene la richiesta. Una volta che l'utente è stato autenticato, in base all'identità dell'utente, l'applicazione deve determinare se l'utente autenticato ha il permesso di eseguire determinate applicazioni (autorizzazione). Per la maggior parte delle applicazioni Web tradizionali, non esiste una granularità fine nel modello di sicurezza, quindi, una volta che l'utente è autenticato, è anche nella maggior parte dei casi autorizzato ad eseguire determinate azioni. Tuttavia, questi due concetti (autenticazione e autorizzazione) dovrebbero essere come due diverse operazioni logiche.

Inoltre, nelle applicazioni web classiche, dopo che l'utente è stato autenticato e autorizzato (principalmente guardando la coppia nome utente / password nel database), le informazioni sull'autorizzazione e sull'identità sono scritte nella memoria di sessione. L'archiviazione delle sessioni non deve essere lato server, come suggeriscono molte delle risposte precedenti, ma potrebbe anche essere memorizzata in cookie sul lato client, crittografato nella maggior parte dei casi. Per un esempio, il framework PHP CodeIgniter lo fa per impostazione predefinita. C'è un certo numero di meccanismi per proteggere la sessione lato client, e non vedo questo modo di memorizzare i dati di sessione meno sicuro di quello di archiviare sessionId, che viene poi cercato nella memoria di sessione sul lato server. Inoltre, la memorizzazione della sessione lato client è abbastanza comoda in ambiente distribuito, poiché elimina la necessità di progettare la soluzione (o di utilizzarla già esistente) per la gestione della sessione centrale sul lato server.

Inoltre, l'autenticazione con una semplice coppia di password utente non deve essere eseguita in ogni caso tramite un codice personalizzato che ricerca il record utente corrispondente nel database. C'è, per esempio protocollo di autenticazione di base , o digerire l'autenticazione. Su un software proprietario come la piattaforma Windows, ci sono anche modi per autenticare la depressione utente, per esempio,ActiveDirectory

Fornire la coppia nome utente / password non è solo un modo per autenticare, se si utilizza il protocollo HTTPS, è anche possibile prendere in considerazione l'autenticazione usando i certificati digitali.

In caso d'uso specifico, se si progetta un servizio web, che usa SOAP come protocollo, c'è anche WS-Security estensione per protocollo SOAP.

Con tutte queste affermazioni, direi che le risposte alla seguente domanda entrano nella procedura decisionale per la scelta del meccanismo di autorizzazione / autenticazione per WebApi:

1) Qual è il pubblico target, è pubblicamente disponibile, o solo per membri registrati (paganti)?
2) Viene eseguito o * NIX o piattaforma MS
3) Quale numero di utenti è previsto
4) Quanto gestisce l'API di dati sensibili (meccanismi di autenticazione più forti o più deboli)
5) Esiste un servizio SSO che è possibile utilizzare

.. e molti altri.

Spero che questo chiarisca le cose, poiché ci sono molte variabili nell'equazione.


8
2018-06-29 17:52



Se l'APP basata su API è un client, l'API deve avere l'opzione per recuperare / leggere i cookie dal flusso di risposta del server e memorizzarlo. Per l'aggiunta automatica dei cookie durante la preparazione dell'oggetto richiesta per lo stesso server / url. Se non è disponibile, l'ID di sessione non può essere recuperato.


1
2018-06-27 09:45



Ti suggerirei di inviare una specie di token con ogni richiesta.

A seconda del server e del servizio, quelli possono essere a JSESSIONID parametro nella tua richiesta GET / POST o qualcosa di simile SAML in SOAP su HTTP nella richiesta del servizio Web.


1
2018-06-29 11:54



Hai ragione, la ragione per cui le cose sono "automatiche" in un ambiente standard è perché i cookie sono preferiti rispetto alla propagazione degli URL per mantenere le cose carine per gli utenti. Detto questo, il browser (software client) gestisce l'archiviazione e l'invio dei cookie di sessione insieme a ogni richiesta.

Nel mondo dell'API, i sistemi semplici spesso hanno solo le credenziali di autenticazione trasmesse insieme ad ogni richiesta (almeno nella mia linea di lavoro). Gli autori dei clienti sono tipicamente (sempre nella mia esperienza) riluttanti ad implementare la memorizzazione dei cookie, e la trasmissione ad ogni richiesta e generalmente qualcosa di più del minimo indispensabile ...

Esistono molti altri meccanismi di autenticazione per le API basate su HTTP, HTTP basic / digest per nominare una coppia e, naturalmente, l'onnipresente o-auth progettato specificamente per queste cose se non sbaglio. Nessun cookie viene mantenuto, le credenziali fanno parte di ogni scambio (abbastanza sicuro su quello).

L'altra cosa da considerare è che cosa farai con la sessione sul server in un'API. La sessione su un sito Web fornisce spazio per l'utente corrente e in genere memorizza piccole quantità di dati per scaricare il db da una pagina all'altra. In un contesto API questo è meno necessario in quanto le cose sono più o meno prive di status, parlando in generale, naturalmente; dipende davvero da cosa sta facendo il servizio.


0
2018-06-28 18:35