2011-11-03 14 views
17

La mia app è strutturata come segue: Ho un servizio web (in esecuzione su GAE, non molto pertinente a questa domanda) e il i dati contenuti in questo servizio sono resi disponibili tramite un sito Web e tramite app mobili e desktop.Come autorizzare le app mobili con una terza parte di oauth MA connettersi al mio servizio, non alla terza parte

Attualmente, l'utente si autentica sul sito Web tramite Google ClientLogin e le app autenticano/vengono autorizzate tramite il provider oauth incorporato di GAE. (OAuth viene utilizzato qui principalmente per l'autenticazione, la mia app in realtà non utilizza alcun dato esterno tramite OAuth diverso dall'ID univoco dell'utente e dall'indirizzo email.)

Quello che mi piacerebbe fare è espandere il numero di servizi che gli utenti possono utilizzare per accedere. A causa del fattore di complicazione delle app, sembra che ho bisogno di OAuth. Ma non posso davvero concettualizzare correttamente come dovrebbe andare questo flusso.

Consente di prendere Facebook come esempio. Quando un'app mobile passa attraverso il flusso di Facebook oauth e acquisisce un token di accesso, questo non è sufficiente, perché è il mio servizio, non l'app, che in realtà ha bisogno di parlare con Facebook per recuperare le informazioni di contatto e un ID utente univoco. Questo mi porta a pensare che il processo OAuth debba avvenire nel contesto del mio servizio e non nell'app mobile. Il mio servizio diventa quindi il consumatore e Facebook l'oauth providor, e il servizio mantiene il token di accesso oauth, questo accade quando un utente imposta il suo account per la prima volta.

Se questo è l'approccio corretto, da dove viene lasciata l'autenticazione per le app? Cosa succede quando l'utente ha già un account e installa una nuova istanza di un'app mobile? Immagino anche di passare attraverso il processo di oauth, abbinando le credenziali con i dati già memorizzati dal mio servizio, e poi emettendo il mio "token di accesso" all'app dal servizio, per autorizzare quell'istanza dell'app. Questo sembra complicato e hackish.

Sono sicuro che non posso essere l'unica persona che è in effetti "in prestito" il sistema di account di una terza parte per un'app mobile con un back-end, ma davvero non vedo quale sia il modo corretto di fai questo.

Cosa non vedo e/o sto concettualmente sbagliato?

+0

* Crickets * Mi sento come se avessi potuto formulare questa domanda in modo errato. Se è così, per favore fatemelo sapere. Altrimenti, risponderò alla mia stessa domanda qui ... alla fine. – tempy

risposta

10

Alcuni colleghi e io una volta ho fatto un progetto abbastanza simile in natura, all'università. Abbiamo autenticato i nostri utenti tramite Facebook o Foursquare, utilizzando le rispettive API OAuth.

La versione nativa di Android dell'app ha aperto uno WebView con la pagina iniziale del provider OAuth, che ha reindirizzato al nostro servizio dopo l'autenticazione. Quindi il nostro servizio ha fatto una richiesta per il token OAuth dal fornitore OAuth (Foursquare ha qualche pretty simple instructions). Quando abbiamo ottenuto quel token, abbiamo impostato una sessione utilizzando i cookie, a cui abbiamo potuto accedere dall'app.

Per convalidare le sessioni, abbiamo appena controllato se il token di accesso era ancora valido con il provider. Abbiamo anche utilizzato gli ID utente unici dei rispettivi fornitori per distinguere gli utenti.

Quindi sì, cosa ha funzionato per noi è: rendere l'applicazione autenticare & autorizzare il servizio di , non l'applicazione stessa.

+0

Quindi, la tua app memorizzava questi cookie e li utilizzava per autenticare il servizio, e dovresti abbinare il cookie al token oauth appropriato sul tuo servizio? È diverso dal generare un guid e consegnarlo all'app? – tempy

+0

Esattamente, l'app utilizzava i cookie memorizzati (contenenti ID crittografati, ecc.) per autenticare il servizio, che poi parlerebbe con i provider OAuth (per verificare se il token era ancora valido). È anche possibile utilizzare una sorta di GUID, ma è necessario rendere difficile la rappresentazione di tale app, ad es. avere qualcosa che solo il server conosce per verificare. – Rich

+1

Per fortuna l'app non ha a che fare con dati particolarmente sensibili nel mio caso. Ma ancora, questo approccio ha senso, ma sembra un po 'troppo "roll your own" ish. È una soluzione, ma mi chiedo se questo è l'approccio di consenso a questo problema. – tempy

Problemi correlati