Il rinnovo del nome utente e della password è un rischio per la sicurezza molto maggiore e non ha alcun vantaggio sugli ID di sessione (o qualche variazione dei token di accesso) che riesco a vedere.
La perdita di una password ha un impatto maggiore
Ecco perché: se l'ID della sessione viene dirottato, l'utente malintenzionato avrà accesso alla sessione, il che è già abbastanza grave. Ma se ottiene il nome utente e la password, può impersonare il servizio per tutto il tempo che desidera (perché di solito le password non scadono, a differenza delle sessioni), può reimpostare la password e bloccarti fuori dal servizio, ecc. , dal momento che molte persone riutilizzano le password su altri siti, la tua password potrebbe anche compromettere i tuoi account su innumerevoli altri siti. Non può fare nulla se ha solo l'id della sessione. Quindi è meglio esporre l'id della sessione localizzata di breve durata al rischio rispetto al nome utente e alla password di lunga durata.
Idealmente, la password non verrebbe mai trasmessa sulla rete (ci sono schemi che evitano di inviare la password, e la maggior parte dei browser e server web sono in grado di usare quelli più semplici (ad esempio, l'autenticazione di google digest), ma sfortunatamente , lo sviluppo di questa tecnologia è stato trascurato a favore dell'implementazione di sistemi di login lato server utilizzando schermate di login di bell'aspetto, che richiedono la trasmissione della password.)
Il dirottamento della sessione è (dovrebbe essere ...) difficile
Rubare un id di sessione non è così facile. Indovinare gli ID di sessione è molto difficile (trilioni di volte più difficili di indovinare la password media) se l'applicazione che li genera sta facendo bene. Gli ID di sessione dovrebbero essere creati come lunghe stringhe casuali usando un generatore di numeri casuali di crittografia; e dal momento che molte sessioni sono valide solo per poche ore al massimo, non c'è molto tempo per fare molte ipotesi. Il passaggio degli ID di sessione come parametri GET nell'URL è un problema, sì, ma questo dovrebbe essere fatto solo per degradare con garbo quando il browser dell'utente non accetta i cookie. La maggior parte degli ID di sessione vengono passati utilizzando i cookie che risiedono nell'intestazione di una richiesta http.
Autenticazione e autorizzazione federate
Infine, il rinvio del nome utente e della password è spesso semplicemente impossibile, poiché potrebbero non essere disponibili. Se si utilizza l'autenticazione federata di un sistema di autorizzazione come OpenID / OAuth, non si ha accesso alle credenziali dell'utente; hai appena ricevuto un token di accesso o ID (o entrambi), che sono una specie di lettera autenticata per dimostrare che sei chi dici di essere e dovresti avere accesso a una determinata risorsa. Ancora una volta, i token di accesso sono validi solo per pochi minuti fino a un'ora e solo per una risorsa specifica, quindi anche se un token di accesso è stato rubato, il danno che qualcuno potrebbe fare con esso sarebbe limitato.
Con OAuth, puoi richiedere un tipo speciale di token chiamato token di rinnovo che puoi utilizzare per ottenere un nuovo token di accesso senza che sia necessario che l'utente effettui nuovamente l'accesso quando scade il vecchio token di accesso. Quindi questo si avvicina alla tua domanda sul rinvio delle credenziali di accesso, perché se il token di rinnovo viene rubato, l'hacker ottiene un accesso quasi illimitato al servizio per il quale è destinato il token. Nota che anche quando un token di rinnovo (che in genere viene tenuto fuori dalla portata dei programmi utente da un server) viene rubato, questo non compromette la password dell'utente e tutti gli altri siti per i quali usa il suo account.
API riposanti
A differenza dei siti web che consentono a un utente di accedere, le API sono spesso senza stato. Quindi il client deve autenticarsi con ogni richiesta fatta all'API. Questo può essere fatto inviando il nome utente e la password ogni volta che si effettua una richiesta, ma molte API risolvono questo problema facendo in modo che un client ottenga un token di accesso usando le sue credenziali, quindi usa il token di accesso per accedere l'API. OAuth è un esempio perfetto per questo. Quindi, di nuovo, la password viene inviata una sola volta per "sessione" per ottenere un token di accesso.