Architettura per autenticazione/autorizzazione di utenti mobili e Web

Question

Questo sembra essere un problema ricorrente per me poiché mi sembra di gravitare attorno alle applicazioni mobili negli ultimi anni. Voglio autenticare e autorizzare utenti mobili oltre agli utenti web. Ho bisogno di renderlo abbastanza trasparente in modo che gli utenti possano facilitare l'accesso a un account Web senza causare interruzioni ai propri dati. Voglio che la soluzione sia architettonica in argomento, non specifica per qualsiasi lingua/framework.

Requisiti/Assunzioni

1. utenti mobili devono essere in grado di utilizzare l'applicazione nativa, senza un account di accesso, anche per contribuire contenuti (marcatura preferiti, caricare foto, ecc).
2. L'utente mobile deve essere autenticato in modo sicuro e univoco per il servizio Web anche senza specificare le credenziali dell'account.
3. L'utente mobile può disporre di più dispositivi, che non saranno a conoscenza l'uno dell'altro.
4. L'utente mobile deve essere in grado di registrarsi/accedere, che dovrebbe inserire qualsiasi contenuto nella proprietà dell'account. Questa "sincronizzazione" dovrebbe verificarsi con ogni account che viene successivamente registrato.
5. Non importa se è stato creato un account su dispositivi mobili o sul Web.

Architetture Considerato

1. NO CAMICIA, niente scarpe, NO LOGIN = privi di contributo. Richiede l'accesso per fornire contenuto di qualsiasi tipo. Ciò impedisce la necessità di "sincronizzare" gli account dispositivo con un account principale. Richiede semplicemente un singolo nome utente/password + token per consentire ai dispositivi di accedere. Oggetti server: Utente, Ruolo
2. Autenticazione multi-dispositivo. Il server negozia con il dispositivo e fornisce le credenziali memorizzate dal dispositivo. Ogni dispositivo si auto-autentica ed è associato a un account anonimo fino a quando non si verifica Register/Login. Se il registro si verifica, l'account anonimo viene convertito in un account noto. Se si verifica l'accesso, il contenuto dell'account anonimo viene spostato su un account noto e quindi gettato via. I dispositivi che perdono i dettagli dell'autocertificazione riceveranno nuovi dettagli di autenticazione e il precedente account anonimo verrà abbandonato (e quindi si spera in seguito gettato via) e non ripristinabile poiché non è mai stato convertito in un account noto. Oggetti server: Utente, Ruolo, Dispositivo

Quale pensi sia una buona soluzione? Uno di questi o qualcos'altro?

Answer 1

Il numero 2 è sufficiente come decisione di base. Gli utenti odiano la registrazione;) Quindi, la capacità di utilizzare il servizio senza registrazione è una buona idea.

È possibile utilizzare GUID/UUID per identificare il dispositivo. E usalo come login anonimo prima di accedere.

Ma cosa fare se 2 (o più) persone usano 1 dispositivo? O il dispositivo sarà licenziato, rubato? Penso che nessuno dei punti riguardi questi casi.

Non ho idea del tipo di servizio Web che architetto non è in grado di consigliare di più.

Answer 2

Vorrei proporre un'idea simile a 2.

Generare un UUID per dispositivo mobile. Servirà per identificare il dispositivo in seguito quando l'utente genera contenuto e il contenuto viene inviato al server.

Se, in un secondo momento, l'utente desidera creare un account Web, può registrarsi sul Web o sul dispositivo. Se l'utente possiede già un account web, può scegliere di fornire le credenziali esistenti sul suo dispositivo mobile una volta (o dispositivi) e il dispositivo è collegato al proprio account Web sul lato server.

Per quanto riguarda il server, consentirei due diversi tipi di entità che fungono da identità: Utenti Web autenticati dalle credenziali (OpenID mi viene in mente come aggiunta) e dispositivi autenticati dal GUID senza interferenze dell'utente. Naturalmente, un'entità utente Web può possedere diverse entità dispositivo. Un'entità dispositivo è collegata a un account quando l'utente sceglie di collegare il suo dispositivo a un account esistente. Il contenuto è generalmente associato a un'identità.

Il collegamento tra utente e dispositivo viene mantenuto e potrebbe anche essere utilizzato per visualizzare l'origine del contenuto.

Non è necessario creare/eliminare/convertire account con credenziali generate per gli utenti mobili. Inoltre, non è necessario memorizzare le credenziali sul dispositivo mobile.

Ci sono ancora alcune considerazioni sulla sicurezza lasciate aperte, a seconda della criticità del contesto dell'applicazione. Senza alcuna misura di sicurezza, un utente malintenzionato potrebbe facilmente abusare dell'UUID.

Answer 3

Penso che questo sia stato guardato dalla direzione sbagliata. Definire un'identità sul server come definita da un valore arbitrario. Probabilmente solo una sequenza DB. Associa qualsiasi informazione demografica (nome, email ...) e cronologia di utilizzo con questa identità.

Separatamente, definire un'entità di autenticazione sul server. Questo potrebbe essere un utente/password. Potrebbe essere un GUID/UUID del dispositivo. Potrebbe essere un ID federato come OpenID. Una determinata identità può avere (e spesso sarà nel tuo caso d'uso) più entità di autenticazione associate. Molto probabilmente più identità di identità dello stesso tipo. (ad esempio GUID per il mio smartphone, GUID per il mio iPad ...)

I front-end (sia basati sul Web o basati su app), utilizzano un'API definita per autenticare un utente; usando tutti i meccanismi supportati dal front-end.

In alcuni casi (in particolare l'app nativa), la presentazione di un ID sconosciuto attiva la creazione di una nuova identità. Tuttavia, come qualcuno ha sottolineato, in questa situazione è necessario chiedere all'utente se desidera connettersi a un'identità esistente. Devono fornire l'autenticazione come tale identità (una sola volta) per stabilire tale connessione.

Un altro punto, qualunque sia il server utilizzato per specificare in modo univoco un'identità, dovrebbe essere un valore che è mai fornito a un client. I client conoscono solo il meccanismo di autenticazione e i suoi dati. Cioè, il GUID/UUID, nome utente/password, ...

In aggiunta alle tecniche sopra elencate, qualcosa come OAuth è più sicuro di un GUID generato localmente. Quelli sono uno di: facilmente determinato o b: facilmente perso. Se il valore è altamente prevedibile (ad esempio il numero di telefono), è facilmente falsificato. Se viene generato in fase di runtime e include un valore difficile da prevedere come l'hash dell'ora corrente quando viene generato per la prima volta, deve essere memorizzato sul dispositivo e può essere facilmente perso se il dispositivo viene cancellato. È possibile generare buoni GUID, ma spesso sono specifici per tipo di dispositivo. Cose come i numeri di serie del dispositivo recuperati dalla ROM, IMEI, ... Questo è facilmente fattibile.Ma è molto più dipendente dal dispositivo specifico di quanto probabilmente mi sarebbe comodo.

Il più grande ostacolo reale che vedo in questo approccio è che sarà difficile consentire a un utente di dispositivo (nessun nome utente/password) esistente di sedersi al browser di un PC e connettersi al suo account esistente.

Answer 4

Una soluzione è con un biometrico. Se il dispositivo mobile ha un sensore biometrico, ad esempio un lettore di impronte digitali, l'utente si iscriverà biometrico al dispositivo (solo, a causa di problemi di privacy) al momento dell'acquisto. Le applicazioni possono essere scritte in modo tale che ogni transazione sicura richieda all'utente di autenticare il biometrico.

Questo non sembra essere troppo lontano. Motorola Atrix ha un sensore di impronte digitali ...