Gestione dell'accesso nelle applicazioni mobili

Question

Gestione dell'accesso nelle applicazioni mobili

#1 da (2 voti)
#2 da (0 voti)

0

Sto programmando un'app mobile che utilizza i servizi REST.

Alcuni dei servizi sono per gli utenti registrati, quindi ho un endpoint di accesso che mi consente di inserire le mie credenziali e ottenere un token JWT per accedere alle API protette.

Voglio poter accedere una sola volta e farmi ricordare dall'app senza che mi chieda di effettuare nuovamente il login ogni volta che chiudo e riapilo.

Ho trovato due scelte finora:

Crea un JWT di lunga durata, che non scade. In questo modo, posso solo salvarlo e usarlo ogni volta che avrò bisogno di accedere alle API protette. Questo può essere pericoloso perché se il token passa in mani sbagliate, l'hacker avrebbe una chiave di accesso che non scade mai. Quello potenzialmente è un accesso permanente all'applicazione.
Salva nome utente e password nella memoria locale dell'app. In questo modo posso avere JWT in scadenza che possono essere aggiornati, e se l'ultimo token è scaduto, posso chiamare di nuovo l'API di login con lo stesso nome utente e password per ottenere un nuovo token. Questo può essere pericoloso perché dovrei salvare le credenziali dell'utente sul telefono, mi sembra rischioso.

Quindi qual è l'approccio comune a questo problema?

rest authentication mobile

posta BackSlash 03.10.2018 - 15:14

fonte

2 risposte

Leggi altre domande sui tag rest authentication mobile

In che modo una risposta asincrona di solito sta tornando al clent nella tipica architettura ad alto carico reattivo? Implementazione delle proprietà del modello dinamico in base al paese

score 2 · Answer 1

I token di lunga durata non sono di solito un problema. Se un utente malintenzionato compromette il dispositivo dell'utente fino al punto in cui potrebbe esfiltrare il token, potrebbe eventualmente catturare anche le password. Se l'utente estrae volentieri il token per usarlo esternamente, quindi nessun danno fatto: il token dovrebbe identificare l'utente, non la tua app.

Ma il problema con i token JWT di lunga durata è che non possono essere revocati senza memorizzare lo stato centralizzato. Una possibile soluzione: non utilizzare JWT. Invece di fornire all'utente un token JWT con attestazioni firmate, può essere preferibile un identificatore di sessione longevo ma revocabile. Ovviamente, ciò richiede che tu memorizzi tutte le sessioni attive nel tuo back-end. Tuttavia, è possibile utilizzare casi come "disconnetti tutte le sessioni attive" nel caso in cui i dispositivi dell'utente oi loro token siano compromessi (probabilmente anche a causa di un problema da parte tua).

Ci sono soluzioni intermedie che puoi provare, ma suppongo che sarebbero più complesse. Ad esempio, potresti scartare le JWT dopo alcuni giorni, ma emettere automaticamente nuovi token regolarmente. In questo modo, un utente non dovrebbe eseguire l'accesso se l'app è in grado di essere eseguita regolarmente (è possibile pianificare un'attività in background per aggiornare il token). Tuttavia, il fornitore di token può rifiutarsi di aggiornare un token se il token ancora valido fornito dall'app viene contrassegnato come revocato. Per esempio. puoi rifiutare tutti i token che sono stati emessi prima di un determinato momento o rifiutare i token con un ID specifico. Altri servizi che utilizzano questo token devono solo controllare la firma, non lo stato di revoca. Ciò limita la finestra di opportunità di utilizzo improprio di token rubati, ma in realtà non impedisce nulla.

Alla fine, la scelta corretta dipende interamente dal tuo modello di sicurezza . Quali minacce stai difendendo contro? Qual è il rischio e l'impatto di questa minaccia? Non esiste una sicurezza perfetta, quindi quali minacce sono importanti? Per esempio. la tipica applicazione bancaria arriverebbe a conclusioni molto diverse rispetto alla tipica app di microblogging.

score 0 · Answer 2

Quindi l'approccio più comune che ho visto è usare oauth2 con un token di accesso breve (5 minuti) e un token di aggiornamento di un mese (1 mese).

Ciò significa che una volta che l'utente effettua l'accesso, può astenersi dall'utilizzare l'app fino a un mese prima che gli venga chiesto di effettuare il login.

Il token di accesso viene inviato con ogni richiesta ai server di resourse e il token di aggiornamento viene utilizzato ogni 5 minuti per ottenere un nuovo token di accesso e aggiornare il token dal server di autenticazione.

Se l'utente desidera "disconnettersi", può chiedere all'autorità di revocare il proprio token di aggiornamento. Dopodiché, il loro token di accesso è valido solo per 5 minuti e sarà necessario accedere nuovamente con il proprio utente / pass.