2009-08-29 12 views
19

Recentemente sono stato contattato per lavorare su un'applicazione che richiede Facebook-Connect come uno dei suoi meccanismi di autenticazione.Facebook-connect o OpenID? Dal punto di vista dello sviluppatore

Lavorando sulla mia soluzione Facebook-Connect, mi sto rendendo conto che sta implementando uno schema di autenticazione Single-Sign On, dove se si accede a un sito Web, si è connessi a tutti loro. Personalmente, non sono affezionato all'approccio e trovo che sia difficile (non impossibile) lavorare quando si cerca di incanalare tutti i sistemi di autenticazione attraverso un singolo processo che tu (lo sviluppatore) hai un certo controllo. Penso anche che introduca il numero security issues (see Risks of Internet Deployment) non necessario per migliorare leggermente l'esperienza utente.

Mentre studiavo le strategie per lavorare con la tecnologia, ho notato che la blogosfera ha quasi unificato Facebook-Connect come il santo graal dell'autenticazione, riecheggiando l'opinione reciproca e chiedendo a gran voce che "OpenID è troppo complicato" . Allo stesso tempo, non ho davvero visto molti importanti sviluppatori e esperti di sicurezza alzare bandiere o esprimere le loro opinioni in merito. La mia unica esperienza con OpenID è con StackOverflow e siti correlati. Anch'io ho avuto difficoltà a capire cosa fosse in un primo momento, ma una volta capito che potevo accedere con le mie credenziali di google, l'esperienza si è dimostrata davvero fluida.

Sono paranoico o mi manca qualcosa che tutti hanno? Facebook-Connect è davvero un'alternativa migliore a OpenID, oppure tutti bevono Kool Aid di qualcuno?


EDIT:

Dopo aver lavorato su questo, confermo che il regime login facebook-connect è proprio l'ideale. L'intera cosa iframe/js/cookie/reload è brutta e può facilmente diventare problematica. Integrare l'accesso fb a un sistema di autenticazione esistente è un esercizio in sé. Dovrai fare dei compromessi. Dovrei scrivere un altro articolo per spiegare come l'ho fatto.

Facebook sembra un po 'ossessionato da Single Sign-On per me. La maggior parte delle persone non sa che Facebook ha OpenID abilitato per il proprio sito, ma anche il modo in cui sono implementati è quello di emulare SSO e renderlo un po 'inutile. Il modo in cui pensavo che OpenID avrebbe dovuto funzionare: vai in un nuovo sito web, se hai un account OpenId, metti l'url, accedi al tuo provider e sei dentro. Puoi quindi procedere a completare le informazioni aggiuntive.

Fb non offre il login OpenID in anticipo. Invece, devi prima registrarti e accedere, quindi andare su Impostazioni account e in Account collegati, selezionare un provider OpenID. Tuttavia, a differenza di StackOverflow che comprende il punto, Facebook ti consente solo di accedere con il tuo OpenID, se chiedi al tuo provider di ricordare quell'impostazione. Perché? Lo rende più simile a SSO. Se non controlli la casella di google che chiede di ricordare, OpenID non funziona su Facebook.

Il login da parte, facebook-connect funziona in generale, ma ci sono ancora molti angoli da arrotondare. Alcune cose che mi hanno fatto tirare i capelli e imprecare a quella api:

  • la documentazione di Facebook è dispersa e non propriamente razionalizzata. Entro la prima ora di apertura, avrai almeno 10 schede aperte nel tuo browser. Se/quando ti imbatti in argomenti interessanti che ritieni possano essere utili in futuro, assicurati di segnalarli correttamente, non affidarti alla navigazione per trovarli di nuovo perché a volte gli articoli chiave sono sepolti in profondità. So che l'approccio wiki alla documentazione delle API ha fatto molti progetti pigri ultimamente, ma comune, questo è Facebook. Dovrebbero avere i mezzi per assumere una squadra per fornire guide utente corrette. Quindi, ricordati di avere una bella cartella dei segnalibri di Facebook prima di iniziare.
  • Ci sono molti metodi nell'API, buona fortuna trovare un esempio di come usarli, devi fare affidamento sull'istinto.
  • molte volte, quando qualcosa non funziona come desideri, nessuno sa perché. Quando si visitano le pagine del forum, vengono fornite spiegazioni sotto forma di ipotesi e voci. per esempio. Al login, perché alcune applicazioni hanno una finestra di accesso pop-up quando altre hanno una finestra di dialogo modale js? è possibile controllare questo comportamento? nessuno è sicuro. Si dice che Facebook stia conducendo dei test senza far sapere a nessuno.
  • non tutto funziona come pubblicizzato. Ad esempio potresti sentirti incoraggiato a utilizzare una funzione, sprecando tempo prezioso per apprenderla, implementarla, eseguirne il debug, quindi scoprire solo che non funziona con facebook-connect quando lo inserisci in un gestore di eccezioni try/catch. per esempio. feed.publishUserAction.
  • facebook si sforza troppo per essere facile da usare. Sprecano risorse preziose spingendo una API automagic che funziona solo metà del tempo (xfbml), invece di incoraggiare gli sviluppatori a sfruttare le loro conoscenze acquisite usando le cose più basilari che hanno dimostrato di funzionare la maggior parte del tempo (pseudo sql + html). per esempio. Ho perso tempo cercando di utilizzare una combinazione di ajax/xfbml/js per estrarre le foto degli amici dal loro server. Funzionerebbe per un paio di richieste quindi smetterebbe di funzionare del tutto. Ho quindi deciso di estrarre i dati direttamente dal loro db utilizzando il loro linguaggio di query di Facebook (fql) e creare il mio markup in html. ha funzionato al 100%. Il mio consiglio per te se sei un vero sviluppatore, non comprare nel mantra "tutto è facile" che facebook cerca di sfamare tutti, non lo è. Oltre a familiarizzare con la API del client di Facebook della piattaforma di programmazione (PHP, Python, Java, ecc.), Investire nell'apprendimento di ciò che è possibile prelevare direttamente dal proprio server utilizzando fql e cosa è possibile fare sul browser con lo JS Client API (da non utilizzare confuso con l'fbjs). Potresti scoprire che i successivi 2 sono tutto ciò di cui hai bisogno per fare la maggior parte delle cose.

Sono sicuro che la lista non finisce qui, ma dalla cima della mia testa eccola.

+0

Ottima domanda! – typeoneerror

+0

@ mike, sono d'accordo nel mantenerlo semplice - usando solo FQL e l'API Javascript quando possibile. Questo è quello che sto facendo con l'app web del mio amico localizzatore. –

risposta

6

Attenzione: forti opinioni seguente.

Sì, stanno bevendo il Kool-Aid. Facebook Connect è un Single Sign-On proprietario e dipendente dal gestore e molto altro. Facebook va giù, o è considerato non degno di fiducia, e tu sei protetto.

OpenID ignora quello.Al momento ha importanti problemi di esperienza utente, ma a lungo termine è una soluzione migliore perché libera il sistema dalla dipendenza (e dal filtraggio di tutto il traffico attraverso) da un singolo provider. Inoltre, le sue specifiche e l'implementazione sembrano molto più pulite - nessuna di queste cose JavaScript/IFrame. Richieste e reindirizzamenti HTTP semplici. Questo ti dà anche una migliore compatibilità con il browser.

Facebook Connect ha risolto il problema dell'esperienza utente, ma a spese del supporto del browser e della scelta del fornitore. È una vittoria pragmatica a breve termine, ma penso che a lungo termine non sia una buona idea.

2

Lo schema Single Sign-on è abbastanza comune ora con le principali app. Se accedi a Gmail, hai effettuato l'accesso a tutti i prodotti Google. Penso che abbia senso in un certo senso, specialmente se le app sono interconnesse, sono un servizio importante e il provider ha le migliori persone di sicurezza che lavorano dietro le quinte.

Ora per OpenID, penso che sia un'ottima idea, ma OpenID non è ancora accessibile. Doveva rivoluzionare l'accesso per i siti web più piccoli e medi, ma non è così. Ci sono molti siti web che lo usano, ma apparentemente non abbastanza. La maggior parte dei siti Web utilizza ancora i propri schemi di accesso, chiamandoli letargia o disagio con un fornitore separato.

Ma penso che prima o poi qualcosa come OpenID emergerà, ma per farlo funzionare ha bisogno di una spinta importante dietro di esso. Qualcuno come Google.

Immagina se tu fossi in grado di accedere SO utilizzando il tuo ID google.

Per ora penso che non è necessario essere a disagio con Facebook-Connect, ma vi consiglio di OpenID, anche se non ho ancora lo uso io stesso :) (letargia)

+0

Mi sento a mio agio con Single Sign On all'interno di una rete di siti correlati. Non ho proprio il senso di avere il mio sito trattato come parte di tale rete quando tutto ciò che voglio è il processo di autenticazione. A proposito, è possibile accedere a SO con il proprio ID di google. Il mio punto è che, anche se la finestra di Gmail è aperta 24 ore su 24, 7 giorni su 7, quando si tenta di accedere a SO, verrà richiesto il nome utente/password. Come sviluppatore mi piace, perché ricevo un flag definito che posso usare per inizializzare correttamente un profilo. –

+0

Penso che OpenID abbia meno "feeling di accesso alla rete" rispetto a Facebook Connect, nel bene e nel male. Personalmente, sono infastidito dal fatto che Facebook abbia inventato il suo protocollo piuttosto che andare con OpenID. Spero che alla fine saranno un OpenID Provider * e * Relying Party completamente in buona fede. Con questo pregiudizio, quindi, ti consiglio di prendere l'itinerario OpenID. –

+0

A volte Google ti fa accedere di nuovo (ma ricorda il tuo nome) quando accedi agli altri servizi di loro, specialmente se non hai ancora effettuato l'accesso a quel prodotto. Questa è una buona cosa, secondo me. – Neo42

0

Hai guardato Google Friend Connect? È simile a Facebook Connect, ma è basato su Open ID, quindi non interamente proprietario di Google. Sembra anche risolvere i problemi di esperienza utente Open ID.

rpxnow.com fa anche un buon lavoro per risolvere il problema di esperienza utente Open ID.

Problemi correlati