Login social nativo vs nativo su client mobili

Question

Login social nativo vs nativo su client mobili

#1 da (1 voti)

1

Ho svolto ricerche su questo argomento per giorni, ma non riesco a trovare riferimenti solidi intorno a questo argomento ..

L'idea fornisce accesso social per app per client mobili. Questo è tutto. La condivisione, l'accesso ai dati dell'utente e altre funzionalità social non sono richiesti.

Personalmente, immagino (specialmente per i giochi multipiattaforma) che idealmente tu possa semplicemente aprire una pagina web in cui avviene il processo di autenticazione. Questo ha il vantaggio di lavorare su qualsiasi piattaforma senza la necessità di gonfiare l'app con SDK social inutilmente gonfiati. Funziona anche in modo coerente su tutte le piattaforme, ti permettono di testare abbastanza bene la presentazione della vista web.

Tuttavia, la maggior parte delle risorse che continuo a trovare continuano a puntare agli SDK da utilizzare o alle API OAuth per avviare il processo di autenticazione. Questo mi lascia chiedermi se fosse possibile implementare in modo sicuro il flusso di autenticazione basato sul web sui client mobili ...

Domanda

Dato che un'applicazione cross-platform ha l'obbligo di fornire specifiche funzionalità di accesso social (tramite Google+ e Facebook):

Avrebbe senso reindirizzare l'utente a un URL speciale all'interno del sito web dell'app per eseguire l'autenticazione, quindi ricevere una richiamata dall'app stessa?
Ci sono dei vincoli di sicurezza (o comunque importanti) compromessi con un approccio del genere che non sto considerando?
Perché questo approccio non è popolare (in particolare i giochi)? L'unico gioco che ho visto andare con questo approccio finora è Pokemon Go su iOS. Mostra una webview che ti registra su Google +.

References:

Per comprendere il flusso un po 'di più e cogliere il contesto dell'autent web sul dispositivo mobile, puoi vedere qui una panoramica di come si è evoluto nelle recenti versioni di iOS e Android (2015):

link

Per capire cosa intendo per gli SDK gonfiabili, dai un'occhiata a questi esempi:

Alcuni problemi presentati dai precedenti SDK:

Impossibile utilizzare IL2Cpp su Android ( bug SDK di Facebook )
Non puoi più utilizzare il codice bit (Google SDK lo disabilita)
Devi introdurre Cocoapods, che rende il processo di compilazione meno portabile

authentication mobile web-services social

posta Mazyod 02.09.2016 - 22:26

fonte

1 risposta

Leggi altre domande sui tag authentication mobile web-services social

Come strutturare e connettere la mia tabella "prezzo" alla struttura della tabella del database relazionale esistente? Utilizzo della memoria su Creazione di una mappa simile a Travian e 441 pulsanti su una pagina

score 1 · Accepted Answer

Divulgazione : sono un ingegnere Auth0.

^{Punto 1.} In teoria non c'è niente di sbagliato nell'approccio proposto, sembra che semplificherà le cose. Guardandolo dall'angolo di sviluppo del software è solo un altro livello di astrazione che nasconde tutti i dettagli cattivi dell'autenticazione con più provider di identità.

Dal punto di vista dell'autenticazione, classificherei il livello di astrazione come provider di federazione. L'applicazione delega l'autenticazione dell'utente a questo unico provider e non si preoccupa di come l'utente viene autenticato, purché il risultato del provider abbia esito positivo, l'applicazione si fida del suo esito, cioè si fida che l'utente sia effettivamente il provider di federazione dice che lo è.

Tuttavia, anche se garantisce l'identità dell'utente, il provider della federazione non gestisce effettivamente lo scambio e la convalida delle credenziali dell'utente e sceglie di delegarlo nuovamente a qualcun altro (Google, Facebook, ecc.). ^{Punto 2.} L'unica considerazione intorno a questo approccio è che devi farlo bene ...

Questo è molto simile a quello che otterresti usando un provider di terze parti che già fa tutte quelle altre integrazioni per te, ad esempio Auth0 si integra con Google, Facebook e una serie di altri fornitori, quindi chi si integra con Auth0 ha solo bisogno di scrivere codice contro una API. Dico API, perché anche se si tratta solo di interazioni basate sul Web, devi comunque rispettare le regole di quelle interazioni basate sul Web.

C'è una differenza però, andare con un fornitore di terze parti a seconda della tua scala ti costerà in definitiva dei soldi, mentre rotolare il tuo ti costerà solo tempo, risorse e una sensazione di affondamento che potresti aver dimenticato qualcosa di veramente ovvio in condizioni di sicurezza. :)

^{Punto 3.} In relazione all'utilizzo nei giochi, onestamente non lo so, ma in altre aree penso che sia piuttosto comune andare con questo, la prova è che ci sono aziende costruite per fornire questo preciso servizio di semplificazione dell'autenticazione contro diverse fonti. Forse i giochi a causa delle loro specifiche esigenze di interfaccia utente preferiscono rimanere all'interno dei reami dell'esperienza nativa.