2009-02-13 14 views
16

L'autenticazione OpenID è intrinsecamente basata sul browser. Se volessi consentire ad un utente OpenID di autenticarsi con un'API da utilizzare in client alternativi, esiste una best practice accettata per questo?Autenticazione OpenID e accesso API

Quindi, se un utente ha provato ad accedere con il suo OpenID a un'app per iPhone, ad esempio, come funzionerebbe? L'unica cosa che posso pensare di generare un token API di qualche tipo per loro e ottenere l'utente per inserirlo manualmente da qualche parte. Questo approccio non è facile da usare.

Questo è il modo in cui siti come Basecamp funzionano, ma a me sembra ancora goffo.

risposta

16

Il problema riscontrato non è esclusivo di OpenID. Qualsiasi schema di autenticazione senza password può avere questo problema. OAuth (http://oauth.net/) è una soluzione che è uno standard aperto che sta rapidamente guadagnando la trazione su molti siti web. È totalmente indipendente dal modo in cui l'utente esegue l'autenticazione, quindi il suo provider OpenID non ha il necessario per supportare o anche essere consapevole del fatto che il proprio sito (il "fornitore di servizi" in termini OAuth) utilizza OAuth. Il tuo client API può essere basato sul web o anche su un'applicazione locale!

Il processo sarebbe qualcosa di simile a questo:

ruoli:

  • l'utente: qualcuno che ha un account con il tuo sito web.
  • provider di servizi: il tuo sito Web, che dispone di un'API programmatica che richiede l'accesso di alcune credenziali.
  • consumer: il client, sia esso un'applicazione web o locale, che necessita dell'accesso all'API del fornitore di servizi.

flusso:

  1. L'utente è al consumatore. Egli indica che vuole accedere ai dati presso il fornitore di servizi.
  2. L'utente viene reindirizzato (se il consumatore è un sito Web) o viene visualizzato un browser (se il consumatore è un'app locale) e l'utente vede il sito Web del fornitore di servizi.
  3. L'utente ha già effettuato l'accesso al fornitore di servizi tramite un cookie persistente oppure l'utente deve prima accedere al provider di servizi, a condizione che ciò avvenga (OpenID nel tuo caso).
  4. Il fornitore di servizi chiede all'utente: "Consumatore (qualche consumatore) desidera l'accesso ai dati (o alla nostra API o altro). Si desidera autorizzare questo? (Sì/no)
  5. L'utente conferma e la finestra del browser si chiude o viene reindirizzato al sito Consumer.
  6. Tramite un po 'di magia del protocollo OAuth, il consumatore dispone ora di una credenziale segreta che può utilizzare per accedere all'API e accedere a qualsiasi informazione utente-privato appena autorizzata.

Ovviamente non riesco a includere l'intera specifica OAuth qui, ma è possibile vedere con speranza da quanto sopra che questo dovrebbe risolvere il tuo problema. t per rendere più semplice l'aggiunta di supporto.

Se si utilizza ASP.NET, suggerisco http://dotnetopenid.googlecode.com/ come ha recentemente aggiunto il supporto OAuth (v3.0 beta 1).

+0

Grazie per questa fantastica spiegazione. –

+0

Sto cercando lo stesso tipo di spiegazioni e la tua risposta ha fatto molti miglioramenti, ma dove mi manca la maggior parte delle informazioni è tra il 5 e il 6. Il tuo "protocollo OAuth ** magic **" non mi aiuta molto: p Sarebbe possibile che tu mi dessi (noi?) maggiori dettagli su dove avviene la magia su come il server restful è sicuro che un utente non fidato abbia un utente ufficialmente connesso? Grazie mille! –

+0

Quella "magia OAuth" è gestita da una buona libreria OAuth o dalla lettura delle specifiche e dall'implementazione di te stesso, ma in breve, il consumatore invia una richiesta finale al fornitore di servizi con un "codice di verifica", in cambio del quale il il fornitore di servizi invia al consumatore un "token di accesso" che può utilizzare per firmare le richieste autorizzate successive. –

1

See: questo related question

Il problema è che la specifica OpenID non ha alcuna disposizione standard per l'autenticazione con il provider, in modo che il provider può eleggere che l'autenticazione avviene tramite una telefonata o qualsiasi altra cosa.

Speriamo più fornitori embrace OAuth. In alternativa è possibile digitare l'autenticazione del codice per alcuni dei siti più grandi.

+0

Posso utilizzare OAuth come utente OpenID supponendo che abbiano già impostato un account con noi? o il fornitore deve supportarlo? –

+0

In OpenID ci sono due ruoli: "OpenID Provider" e "Relying Party". In OAuth ci sono due ruoli: "Service Provider" e "Consumer". È confuso perché in OpenID 1.1, il Relying Party era chiamato Consumer. In ogni caso, il provider OP non ha bisogno di supportare OAuth. Vedi la mia risposta. –

2

Quello che vuoi non è possibile con OpenID. OpenID si basa sulla premessa che tu (l'app per iPhone) vuoi solo sapere dei tuoi utenti che il loro fornitore di OpenID si fida di loro. Non si autenticano mai a te.

Buone OpenID-fornitori in realtà anche prevent che mediano il processo di autenticazione (in quanto ciò esporrebbe gli utenti a un possibile attacco - da voi!): Chiedono che gli utenti login direttamente con loro e si rifiutano login-by-rinvio.

+0

Questo è inaccurato. OpenID riguarda l'autenticazione degli utenti - non preclude altri mezzi di autenticazione/autorizzazione per l'accesso API. Questo è tutto ciò che riguarda OAuth. –

+1

Sto solo rispondendo alla domanda: "Se volessi consentire ad un utente OpenID di autenticare contro un'API da utilizzare in client alternativi ..." - questo non è possibile controllare: il provider controlla la modalità di interazione, non il consumatore. Lo dici anche tu nella tua soluzione ... – yungchin

4

Né OpenID né OAuth definiscono come un utente effettua l'autenticazione. Definiscono in che modo il consumatore indirizza l'agente utente al provider di autenticazione, in che modo viene reindirizzato l'agente utente e in che modo il consumatore può verificare l'identità autenticata dall'utente.

Il metodo effettivo utilizzato per l'autenticazione è fuori banda per entrambi gli schemi.

Esistono differenze tra OpenID e OAuth, ma entrambi richiedono che l'utente utilizzi i reindirizzamenti HTTP e gli URL di callback. Sono entrambi basati sul browser. Se la tua app parla come HTTP, può farlo. Tuttavia, un punto principale è che l'utente sta inserendo le credenziali solo in un'app di fiducia.