OAuth2 vs Public API

4

La mia conoscenza di OAuth (2.0) è che è uno stack software e un protocollo per consentire a più di 2 app Web di condividere informazioni su un singolo utente finale. L'utente A è un membro del sito B e del sito C; Il sito B vuole recuperare alcuni dati dal sito C sull'utente A, ed è qui che entra OAuth.

Per prima cosa, se questa valutazione non è corretta, per favore inizia chiarendo questo per me e correggendomi!

Supponendo che io sia sulla strada giusta, allora suppongo di non vedere la necessità che OAuth inizi con (!). Sono sicuro di non vedere la "foresta tra gli alberi" qui, ma per come la vedo io, il sito C non può esporre un'API pubblica che il sito B potrebbe utilizzare per recuperare gli stessi dati (senza OAuth) ? Se il sito C richiede le credenziali dell'utente per accedere ai dati, questa API pubblica può utilizzare solo HTTPS per il trasporto sicuro e richiedere nome utente / password come parte di ciascuna chiamata API?

Ancora una volta, sono sicuro che mi manca qualcosa, ma non sto capendo perché avrei bisogno di OAuth quando un'API pubblica, sicura, scritta ed esposta dal Sito C sembra più che in grado di fornire ciò che il Sito B ha bisogno riguardo Utente A.

In generale, sto cercando una serie di linee guida da seguire quando decido di scegliere se utilizzare OAuth per le mie app Web o semplicemente scrivere il mio servizio web (esponendo l'API pubblica).

Grazie in anticipo!

    
posta herpylderp 02.07.2012 - 15:10
fonte

3 risposte

10

OAuth non riguarda l'esposizione di un'API. OAuth riguarda l'autorizzazione: il sito B è autorizzato ad accedere alle risorse dell'utente A.

Prima che Twitter iniziasse a implementare OAuth, utilizzava l'autenticazione di base HTTP. Ciò significava che gli utenti dovevano fornire le proprie credenziali a siti Web / servizi di terzi per consentire loro di accedere ai propri dati. Ciò significa che il sito Web ora ha accesso illimitato ai dati degli utenti e l'unico modo per "revocare" quell'accesso è cambiare la password.

OAuth risolve questo problema non dando al sito web le credenziali degli utenti, ma un token. Questo token fornisce loro (possibilmente limitato) l'accesso alle risorse degli utenti, senza avere alcuna password. Se un utente desidera bloccare questo sito web, deve solo revocare il token e tale sito / servizio non ha più accesso.

    
risposta data 02.07.2012 - 15:43
fonte
4

OAuth è uno standard aperto che non richiede agli utenti di trasferire le proprie credenziali su diversi siti diversi. Danno solo le proprie credenziali a un sito, quindi gli altri siti possono autenticare i propri utenti con il proprio sito senza chiedere un nome utente / password. Hai già visto questo vantaggio quando accedi al tuo account qui.

Potresti implementare la tua soluzione personalizzata, ma questo elimina i vantaggi dell'utilizzo di uno standard aperto. L'utilizzo di uno standard aperto consente due cose:

  1. Puoi utilizzare altre librerie open source per implementare il tuo servizio OAuth piuttosto che reinventare la ruota.
  2. Non costringerai altre persone a scrivere la loro logica personalizzata per l'autenticazione con il tuo sito. È meglio consentire alle persone una familiare interfaccia OAuth piuttosto che costringerli a imparare un'altra nuova API.
risposta data 02.07.2012 - 15:38
fonte
1

In parole povere, se stai esponendo un'API, chiedi all'altro sito di passare nome utente / password all'API in modo da verificare tali credenziali e l'utente può iniziare a utilizzare l'altro sito.

Tuttavia, con OAuth l'utente non fornisce nome utente / password o credenziali di accesso all'altro sito ma direttamente al tuo sito.

Questo perché è una violazione della sicurezza che l'altro sito richiede le credenziali di accesso dell'utente che effettivamente appartiene al tuo sito.

    
risposta data 02.07.2012 - 15:43
fonte

Leggi altre domande sui tag