2014-07-26 7 views
17

Sto sviluppando un'app con entrambe le opzioni di Facebook e Google per l'accesso, oltre a un classico accesso e-mail + password. Mi sto interrogando su diverse cose riguardanti l'accesso con API di terze parti:Best practice (migliore per Android): autenticare un utente con Facebook o Google login

1. dal momento che un utente può accedere con il suo account Facebook e in seguito decidere di disconnettersi e accedere con il proprio account Google, il l'utente dovrebbe essere riconosciuto dal suo indirizzo e-mail. Pertanto, ogni volta che accede a un altro account, l'indirizzo e-mail viene ricercato nel database e, se viene trovato, allega questo nuovo collegamento all'account creato in precedenza. Approvo solo questo punto, per favore.

2. Se l'utente si a Facebook login, è possibile ottenere un access token, userId, utente e-mail, ecc Qual è la prassi migliore per autenticare l'utente in modo che sia ancora il modo più sicuro? Devo inviare il suo accesso a Facebook e indirizzo e-mail direttamente al server? Il server dovrebbe controllare contro Facebook, se l'accesso ai cookie esiste davvero su Facebook? Qual è il modo migliore e più sicuro per generare un token di accesso privato dell'applicazione sul lato server? Ho sentito qualcosa riguardo l'hash MD5 ... Dovrei quindi utilizzare solo questo token di accesso appena generato nelle chiamate API e non utilizzare nessuna delle credenziali di Facebook? O dovrei usare le credenziali di Facebook e quindi salvarle sul lato server/client? Ho intenzione di utilizzare Java App-engine per il lato server della mia app.

3. Cosa succede se l'utente elimina il suo account su Facebook? Come lo saprà l'app? Se lo sa comunque, cosa dovrebbe fare con l'account?

  1. Devo controllare regolarmente il token di accesso su Facebook se è ancora valido? Perché, come e quanto spesso?

Non sono sicuro di chiederlo nel posto giusto. Se ho torto, per favore, reindirizzami nel modo in cui dovrei andare, magari qualche link su queste buone pratiche? Finora, non ho trovato nulla che risponda a TUTTE le mie domande. Credo che sia la codifica e la sicurezza siano collegati. Grazie per tutti i tuoi suggerimenti e trucchi.

+0

Questa è una soluzione davvero lunga ma pochi giorni fa Google ha aggiunto identity-toolkit nei loro progetti googleGitHit GitHub; https://github.com/googlesamples/identity-toolkit-android. E la pagina web principale di identity-toolkit sembra riferirsi liberamente alle problematiche simili che stai chiedendo; https://developers.google.com/identity-toolkit/. Tutto questo è qualcosa che non so quasi nulla ma la tua domanda mi ha ricordato questo. – harism

+0

Grazie! Potrebbe aiutare a rispondere ad alcune delle mie domande. – vandus

risposta

9

Dopo un po 'di lettura e chiedendo mi sono venuti fino a questo:

1. Sì, se si desidera che gli utenti a firmare con il proprio account Facebook o Google, si chiama l'API, arriva l'e-mail indirizzo (è ancora più semplice con AccountManager di Google su Android), inviarlo al tuo server che salverà l'indirizzo e-mail, assocerà un ID utente e genererà il proprio codice di accesso. Il codice di accesso verrà inviato nuovamente all'app client per memorizzarlo per un uso successivo. Ogni volta che l'utente desidera eseguire alcune operazioni, l'API del server verrà chiamata con l'indirizzo e-mail e il codice di accesso dell'utente e si può essere sicuri che sia davvero l'utente. È molto più difficile chiamare l'API dall'esterno e indovinare correttamente sia l'indirizzo di posta elettronica che il codice di accesso in modo che sia alquanto sicuro.

2. Dal momento che il login di Facebook viene utilizzato solo per autenticare l'utente, il che significa solo verificare che l'utente esista e abbia un account, in realtà non abbiamo bisogno dell'accesso FB. Avremmo bisogno dell'FB accessToken solo per le chiamate API per il server di Facebook, quindi ad esempio quando vogliamo recuperare un elenco di amici dell'utente e così via. In questo caso, è possibile ottenere la sessione attiva fornita da Facebook SDK e ottenere da lì l'accesso ai percorsi.

3. Questo caso è ancora piuttosto semplice. Se si utilizza solo l'accesso di Facebook per autenticare l'utente, non ti interessa se l'utente elimina il suo account in futuro. Dopo il primo accesso, si salva il suo indirizzo email, possibilmente un'immagine e non interessa più il suo profilo Facebook. Se usi il login di Facebook per ottenere un elenco di amici e così via, non conservi comunque questo tipo di dati nella tua memoria locale, così, non appena l'utente cancella il suo account, perde anche la sua lista amici. Oppure, puoi tenere la sua lista amici e cercare di aggiornarla ogni volta che usa la tua app e, una volta eliminato il suo account, la lista amici smette di essere aggiornata ed è, ancora, il tuo utente a non utilizzare l'account Facebook. L'ultima idea sarebbe piuttosto adatta a casi di utilizzo di giochi ... solo un'idea, non qualcosa che sia ufficialmente accettato come il migliore.

1

È possibile farlo in diversi modi e sta a voi sull'attuazione, si può avere la tua email ricevute da ogni login hash e salvarlo come un utente nel database . Quindi, per ogni utente che accede può passare e cancellare l'email restituita e verificare se l'hash esiste già.

È inoltre possibile avere l'accesso utente con un servizio e quindi terminare la creazione dell'utente con nome utente, password e-mail ecc. Quindi quando si tenta di accedere con un servizio differenziale è possibile farlo passare nuovamente attraverso la registrazione con un Ho già un pulsante account e il collegamento a un account se provi a creare lo stesso account due volte.

Salva i token associati in una tabella di token di accesso di terze parti collegata a un utente.

vi consiglio di hashing tutti i dati privati ​​degli utenti, offre agli utenti più fiducia con la tua applicazione

Non mi piace mai fare affidamento su conti di terzi e credete al "completare la creazione del tuo account" processo creerebbe una migliore gestione dell'account. Permettere agli utenti di accedere con terze parti o nome utente e password.