Con OAuth 2.0, è piuttosto semplice per uno sviluppatore autenticare un utente tramite un altro servizio al fine di ottenere i suoi dati, ad es. ricevere tweet da un utente di Twitter o dati di fitness tramite RunKeeper, senza conoscere le credenziali dell'utente.
Che cosa è stato utilizzato prima di OAuth 1.0 e quali altre tecnologie vengono utilizzate? Le credenziali erano spesso esposte allo sviluppatore / al servizio prima di OAuth?
"Back in the day" non avevamo alcun standard prima di oauth, tutto era a mano e personalizzato. (quindi, ad esempio, l'API photobucket ha fornito il proprio meccanismo di autenticazione diretta.) Solitamente l'autenticazione basata su token con una chiave API (o anche solo credenziali).
In quel momento la maggior parte dei servizi online erano "isole" e non fornivano molto in termini di scambio di dati o single-sign-on.
In situazioni più "serie" (ad esempio transazioni con carta di credito), spesso si trattava di una combinazione di IP, token di autenticazione e un URL POST-BACK personalizzato.
Il web era un posto molto molto diverso 20 anni fa rispetto a come è oggi.
Esistono diverse tecniche che vengono ancora utilizzate accanto a OAuth.
e spesso una combinazione di essi.
Ciò che hai visto spesso era una combinazione di whitelisting e una delle altre tecniche.
OAuth è stato progettato per limitare la "perdita" dilagante delle credenziali di accesso dell'utente, implementando un sistema di token e autenticazione (non basato sulle informazioni dell'utente)
è persino progettato pensando di sostituire il sistema di Username / password tradizionale. (in congiunzione con openid che fa una cosa simile con altri meccanismi, che funzionano incredibilmente all'unisono).
Ricorda nel web 0.99, l'idea era di mantenere un certo livello di controllo sull'accesso alle risorse. Quindi, come sviluppatore del middleware, otterresti una combinazione utente + password che identificherà in modo univoco le tue richieste su molti schemi di trasporto diversi (Internet non è solo www). L'idea si estendeva non solo all'atto dell'accesso, ma i dati stessi avevano uno schema che poteva non essere stato così leggibile fino a quando non avevi biforcato denaro per l'accesso. xml e i fogli di stile di trasformazione erano il risultato finale: sono l'equivalente basato su tag di ASN.1 e BER.
Ora, l'obiettivo a lungo termine dei servizi di single sign-on ha permeato l'intero ecosistema e, insieme alla diffusione della condivisione di informazioni leggibili / utilizzabili (json!), ha portato la combinazione openid / oauth come mezzo per essere in grado di per gestire gli scopi di controllo sull'uso e l'accesso alle informazioni.
Leggi altre domande sui tag authentication oauth