iOS e server: strategia OAuth

6

Sto provando a lavorare su come gestire l'autenticazione quando ho client iOS che accedono a un server Node.js e voglio usare servizi come Google, Facebook ecc. per fornire l'autenticazione di base per la mia applicazione. La mia idea attuale di un flusso tipico è questa:

  1. L'utente tocca un pulsante Facebook / Google che attiva le finestre di dialogo OAuth (2) e autentica l'utente sul dispositivo. A questo punto il dispositivo ha gli utenti che accedono al token. Questo token viene salvato in modo che la prossima volta che l'utente utilizza l'app possa essere recuperato.

  2. Il token di accesso viene trasmesso al mio server Node.js che lo memorizza e lo contrassegna come non verificato.

  3. Il server verifica il token effettuando una chiamata a Facebook / google per l'indirizzo email dell'utente. Se funziona, il token viene contrassegnato come verificato e il server sa che ha un utente verificato. Se Facebook / google non riescono ad autenticare il token, il server dice al client iOS di autenticarsi nuovamente e presenta un nuovo token.

  4. Il client iOS ora può accedere alle chiamate API sul mio server Node.js passando il token ogni volta. Finché il token corrisponde al token memorizzato e verificato, il server accetta la chiamata.

Ovviamente i token hanno limiti di tempo. Sospetto che sia possibile, ma altamente improbabile che qualcuno possa annusare un token di accesso e tentare di usarlo entro la sua durata, ma a parte questo spero che questo sia un metodo ragionevolmente sicuro per la verifica degli utenti sui client iOS senza dover eseguire il rollover propria sicurezza.

Qualsiasi opinione e consiglio benvenuto.

    
posta drekka 25.06.2012 - 03:31
fonte

1 risposta

8

Sì, qualcuno potrebbe potenzialmente vedere questo token nel pacchetto, motivo per cui è anche una buona idea usare la crittografia SSL di tutto il traffico di rete prima e dopo l'autenticazione e la distribuzione di un token.

Qualcuno su una rete wireless non crittografata, come in uno Starbucks, usa questo metodo tutto il tempo per raccogliere pacchetti per servizi come Facebook che non richiedono il traffico crittografato SSL. Possono quindi utilizzare questo token nelle proprie richieste per spoofare un'altra sessione di utenti.

Allo stesso modo, se io sono un hacker e dovessi compromettere un particolare computer dietro un firewall in cui passa il traffico di rete, diciamo un bilanciamento del carico, posso quindi utilizzare tali informazioni per determinare credenziali e token di sessione sul traffico non criptato che passa attraverso .

Il modo appropriato per gestire questo è di utilizzare la crittografia SSL, anche se si tratta di un certificato autofirmato, quindi ci si assicura che terze parti non possano ascoltare le richieste degli utenti.

    
risposta data 25.06.2012 - 04:28
fonte

Leggi altre domande sui tag