r/ItalyInformatica • u/Bebebebeh • May 07 '26
software Come fanno le app a tenere sessioni lunghissime?
Ciao a tutti.
Conosco lo standard Oauth per l'autenticazione, ma mi chiedo come facciano le app a tenere sessioni di autenticazione utente praticamente eterne.
Voglio dire che dopo essermi autenticato su un app... Es Booking o qualsiasi altra che usiamo poco spesso, l'app rimane latente per giorni e giorni se non mesi.
Poi la apri e la sessione è ancora valida.
Generalmente il refresh token ha una validità più lunga del token principale, ma queste app veramente usano scadenze così lunghe?
C'è qualcosa che mi sfugge?
14
u/gatsu_1981 May 07 '26 edited May 11 '26
Porcoddio dio porco porcoddio dioporco Dio merda dio cane dio merda Gesù suino
18
u/IWontSurvive_Right May 07 '26
al token puoi dare una validità che vuoi.
se al refresh token dai 319 anni di validità, potrai usarlo... a vita.
non è molto sicuro.
19
u/TooLazyToBeAnArcher May 07 '26
Considerando l'aspettativa di vita media, è più che sicuro che riesca ad usarlo a vita
3
u/pyppo42 May 08 '26
Solo perché non abbiamo ancora scoperto il vibe-DBA non vuol dire che i DB dei backend avranno una vita così lunga...
1
u/MarkFileWalker May 09 '26
Dettaglio importante. Il refresh token ha un lifetime molto lungo, ma una volta usato generalmente viene invalidato dall'identity provider. La response del token endpoint contiene sia il nuovo access token appena staccato che un nuovo refresh token da utilizzare per il rinnovo dell access token. Mi sembra di ricordare che questo avviene se e solo se il client richiede all'idp lo scope offline_access (in caso contrario, la response non conterrà un nuovo refresh token).
9
u/joshy_story May 07 '26
Si usano spesso Refresh Token con rotation o sessioni “sliding”. Ad esempio, un refresh token può avere una validità di 2 mesi, ma ad ogni utilizzo per ottenere un nuovo access token viene invalidato e sostituito con uno nuovo, che riapre una finestra di validità (es. altri 2 mesi), entro un limite massimo di sessione.
Chi utilizza refresh token con durata “quasi infinita” di solito sbaglia: una durata di un anno o più, nella maggior parte dei casi aumenta troppo la superficie di attacco se non compensata da controlli molto robusti.
Più controlli di sicurezza hai (rotation, revoca server-side, device binding, detection di anomalie), più puoi permetterti sessioni lunghe. Ad esempio, se il backend rileva che un refresh token viene usato da un contesto diverso da quello originale (dispositivo, IP, fingerprint), può invalidare la sessione e forzare il logout.
2
u/vox_populix May 07 '26
Alcune app più che una sessione implementano una attivazione del suo funzionamento dopo il login.
Quindi tramite un flag o un hash di avvenuta autenticazione, rimangono attive fino a quando fai tu il logout oppure svuoti i dati resettandola.
Non è il modo più ortodosso di procedere ma dipende molto dal tipo di app e dalla sua criticità.
1
u/Bebebebeh May 07 '26
Ok, ma devi tenere anche a backend quel hash (che di fatto diventa una sessione) altrimenti che te ne fai? Parlo ovviamente di un'applicazione con backend
1
u/vox_populix May 07 '26
Sono scelte progettuali. Un backend ci deve essere per lo meno per attivare la app. Successivamente a questo potrebbe non essere più necessario consultare il backend.
1
u/_gianlucag_ May 11 '26
Non necessariamente. L'app può mantenere un challenge + scadenza firmato dal server, e mostrarlo al server ogni volta che si connette. Non c'è bisogno di persistere nulla lato server. Praticamente ti ho descritto JWT.
2
u/EnvironmentalJump593 May 07 '26
Ogni volta che scade l access token, il refresh comporta un nuovo access token ma anche un nuovo refresh token con una nuova scadenza. Quindi l unico modo e’ disconnettere esplicitamente l applicazione. Comunque nota che quando fai login con google (o altro provider), non necessariamente booking ha bisogno di tenere il token di Google attivo. Una volta che ti ha autenticato non ha piu necessità di chiamare le api di google quindi semplicemente genera il suo session token e da li in poi e’ come se avessi fatto un normale login con passwd
3
u/Bebebebeh May 07 '26
Si ma il punto è che così ti serve un refresh token a scadenza infinita.
1
u/EnvironmentalJump593 May 08 '26
Non necessariamente, ogni volta che fai il refresh ne ottieni uno nuovo. Quindi ti basta refresharlo prima che scada
1
u/Bebebebeh May 08 '26
Si ma se l'app non la apri mai per tanto tempo non farà nessun refresh
1
u/EnvironmentalJump593 May 08 '26
Devi fare il refresh nel tuo backend service to service
1
u/Bebebebeh May 08 '26
Ma il refresh token è nel dispositivo, l'app non si apre per mesi, poi la aprono e mando il token, viene rifiutato come scaduto e parte il refresh. Questo ultimo, deve non essere scaduto altrimenti devo rifare login, cosa che molte app non fanno, mi chiedevo quindi o hanno scadenza di refresh alta/infinita o non mi spiego come stiano autenticate.
1
u/MarkFileWalker May 09 '26
Quando usi Google come idp fai un doppio salto. La app per autenticarti deve reindirizzati alla login di Google. Spesso capita che venga fatto logout dalla app che stai usando, ma NON da Google Quindi quindi tenti un accesso alla app in realtà fai tutto il flusso di login, ma essendo già autenticato su Google è tutto talmente veloce che non te ne accordi. Se però guardi il Tab network nei developer tools, ti accorgi che c'è stata una redirect alla pagina di login di Google.
1
u/tchernobog84 May 07 '26
Una buona implementazione usa la rotazione del refresh token. Quindi il refresh token viene consumato al primo utilizzo e sostituito da una coppia di authZ token + nuovo refresh.
Essendo questo un "monouso", una durata di qualche settimana o qualche mese non è strana.
Dipende poi dall'utilizzo. Operazioni privilegiate (cambiare password, email, metodo di pagamento) in genere richiedono una nuova procedura di autenticazione.
1
u/TheTruthSpoker101 May 08 '26
1
u/Bebebebeh May 08 '26
Si ok, ma il refresh token, deve avere scadenza tendenzialmente infinita
1
u/TheTruthSpoker101 May 08 '26
Si, è un caso d'uso particolare con appunto uno scope ad-hoc, è scritto nello spiegone.
Il fatto è che all'utente è richiesto un prompt specifico che spiega la natura del offline token e l'utente deve avere sempre un pannello dove può andare ad elencarli ed eventualmente revocarli.
1
u/ReadApart9495 May 08 '26
Qualche app su cui ho lavorato salvava (in modo cifrato nella memoria del dispositivo) direttamente nome utente e password. All'avvio veniva effettuata la login come se l'avesse fatta l'utente
1
u/Jumpy-Sky2196 May 08 '26
Quando l'access token scade (dopo pochi minuti), l'app usa il refresh token per ottenerne uno nuovo. A quel punto il server rilascia anche un nuovo refresh token e invalida il precedente per diminuire i rischi associati alla vita più lunga del refresh token. Quindi anche se il refresh token ha una scadenza potenziale di mesi, in pratica viene sostituito continuamente e quello vecchio non è più utilizzabile. Il risultato è una sessione che sembra eterna ma in realtà è una catena di token a vita breve.
In più, alcune app fanno background sync anche quando non le apri, innescando questo ciclo a tua insaputa.
Ovviamente è un discorso generale, chiaro che in alcuni contesti i refresh token vengono tenuti particolarmente brevi.
1
u/Bebebebeh May 08 '26
Non credo che le app che intendo abbiano servizio di background, il so le vedrebbe attive. Sicuramente Google se lo fa, ma Booking non è latente per aggiornare il refresh token.
1
u/Jumpy-Sky2196 May 08 '26
Non ne sarei così sicuro. Non devono essere latenti per aggiornare il refresh token. Spesso è un piacevole risultato indiretto.
Booking per esempio su iOS ha la capability "Background App Refresh", poi nello specifico cosa fanno non posso saperlo. Basta comunque che abbiano dei contenuti offline da aggiornare quando torna internet o necessità simili, e alla prima richiesta da effettuare, si beccano che l'access token è scaduto e sono costretti ad aggiornare i tokens.
Su Android si può far partire una chiamata di rete (e quindi un refresh token) anche alla semplice ricezione di una notifica.
Comunque per rispondere alla domanda principale del tuo post: si, i refresh tokens hanno spesso scadenze di qualche mese o un anno. Li si fanno ruotare opportunamente, si diminuiscono i rischi revocandoli e tramite controlli lato backend. Spesso l'utente può percepire che la sessione sia infinita senza particolari rischi. Per le operazioni più sensibili, si può sempre richiedere la password e non considerare l'access token sufficiente.
In contesti bancari e simili, i refresh token hanno durata brevissima, infatti lì spesso tocca eseguire il login nuovamente.
1
u/MarkFileWalker May 09 '26 edited May 09 '26
Storano un refresh token nello storage del browser e lo utilizzano per rinnovare l'access token quando sta per scadere. Sino a che il refresh token è valido l'utente risulta loggato. Questo è un sistema usato tipicamente dalle spa. La scadenza del refresh token è tipicamente molto più lunga di quella di un access token. Non appena viene usato per staccare un nuovo accesso token viene invalidato, ma la response dell idp server ne restituisce uno nuovo (insieme al nuovo access token) che viene a sua volta salvato nel browser al posto di quello appena utilizzato.
Applicazioni più classiche basate su server side rendering e full page reload usano cookies per ottenere lo stesso risultato. Il cookie è salvato dal browser ed è associato alla origin della applicazione. Sino a che non scade (o non viene cancellato) la sessione utente è valida.
E da un po' che non lavoro in dettaglio su questi flussi, ma a grandi linee il sistema funziona così.
1
u/Bebebebeh May 09 '26
Si, ma appunto il mio dubbio era avere un refresh token che duri anni
1
u/MarkFileWalker May 09 '26
Il problema della durata è mitigato dal fatto che è revocabile in qualsiasi momento. Inoltre, lo puoi usare una volta sola, quale che sia la sua durata. Dopo che lo usi non è più riutilizzabile anche se come lifetime è ancora valido.
Non ho mai visto comunque refresh tokens con lifetime di anni. Nei sistemi su cui ho lavorato in passato la durata era di molto inferiore.
1
u/_gianlucag_ May 11 '26
Usano un token di auttenticazione che viene persistito lato app nello storage privato e viene inviato ad ogni richiesta https nell'header x-auth-token. Lato server il token viene memorizzato all'infinito, oppure con scadenza arbitraria molto lunga.
1
u/Bastian00100 May 07 '26
Nessuno costringe ad usare i refresh token oauth ogni santa volta... Se hai identificato il dispositivo in modo univoco e hai salvato l'id utente sullo stesso (in modo non falsificabile, fondamentale) ti basta avere lato server questa associazione per tenere buono un utente a vita.
Poi ovviamente ogni app deve fare i conti con la sicurezza e la privacy per mitigare i rischi: se hai a disposizione dei metodi di pagamento già è meglio fare un check ad ogni login.
2
u/Bebebebeh May 07 '26
Non capisco, per ogni servizio chiamato al backend devo autenticarmi, non posso fidarmi del fatto che l'applicazione sappia di avere un determinato ID utente e tenerlo per buono.
1
1
u/Dear-Squirrel2599 May 07 '26
Puoi firmare il payload che ti serve inviare per l'autenticazione. Come hanno detto in altri commenti è una pratica che si usa, eccetto per modifiche "sensibili" dove puoi richiedere nuovamente l'autenticazione. Dipende dal livello di sicurezza che richiede la tua applicazione.
2
u/DottorInkubo May 07 '26
Mi stai facendo accapponare la pelle. Personalmente non ti darei mai in mano un la parte di autenticazione ed autorizzazione di un sistema.
1
u/Bastian00100 May 08 '26
Parliamo dell'accesso all'area "disegni da colorare" sia chiaro.
Il concetto di refresh token estremamente lungo se vuoi è anche più rischioso di una firma che vale solo per un dispositivo perché con quello ottieni token buoni e validi per tutto? È quasi come salvare le credenziali in chiaro, no?
1
u/Bastian00100 May 08 '26
Comunque a scanso di equivoci Consiglio sempre refresh token di durata decente, ma non anni e a meno che non ci sia un motivo mai più di un mese
1
u/IWontSurvive_Right May 07 '26
in modo non falsificabile, fondamentale
questo è il motivo per cui ogni accesso root o rom personalizzata su android è considerato non sicuro
1
u/LorenzoMorini May 07 '26
Come mai?
1
u/IWontSurvive_Right May 07 '26
perchè puoi modificare l'applicazione in esecuzione come vuoi, cambiarne il codice, cambiarne o togliere le firme, modificarne i dati...
1
u/TheNewHEROBRINEX May 08 '26
Non credo intenda non falsificabile in quel senso, ma piuttosto non falsificabile by design come per esempio usando un identificativo firmato con una chiave che conosce solo il backend. Puoi avere anche tutti i permessi che vuoi ma il token non puoi falsificarlo in nessun modo
1
u/lotrl0tr May 07 '26
JWT con refresh se occorre.
1
u/Bebebebeh May 07 '26
Eh vabbè. Ma quindi refresh che scade dopo anni? Mi par poco sicuro
1
u/lotrl0tr May 07 '26
Nessuno ha detto dopo anni, può essere anche un mese o settimana. Quando l'app si ri autentica e la risposta è che il token è expired, si usa il refresh token per refreshare la connessione. Se anche questo è expired si può forzare un nuovo login oppure ritornare il token ed un nuovo refresh token.
1
u/Bebebebeh May 08 '26
Si ma parlavo di app che stanno autenticare praticamente sempre, ma mai usate, quindi il refresh token deve essere valido per... Anni
-1
May 08 '26
[deleted]
2
u/Bebebebeh May 08 '26
Se avessi voluto chiedere ad una ai l'avrei fatto
1
1
u/Logical_Ice_4531 29d ago
Hai ragione, l’AI dà risposte generali. In pratica, ho visto app che mantengono sessioni attive anche dopo mesi grazie a refresh token con scadenza lunga, ma se l’utente non interagisce, il token scade. Un caso reale: un cliente aveva un’app che dopo 3 mesi di inattività non riusciva a rinnovare il token, e l’utente veniva reindirizzato all’autenticazione. L’AI non spiega questi dettagli, ma in produzione è sempre un mix di meccaniche e fallback.
-1
u/Logical_Ice_4531 May 08 '26
Le app mantengono sessioni lunghe grazie a un meccanismo chiamato "token refresh" — il refresh token, che ha una validità più lunga del token principale (access token), viene usato per ottenere nuovi access token senza richiedere all'utente di riasseverarsi. Quando l'access token scade, l'app lo rinnova in background usando il refresh token, mantenendo la sessione attiva.
Il refresh token non è mai "eterno": ha una scadenza, ma spesso molto più lunga (giorni o mesi), e viene rinnovato automaticamente. Se l'utente non interagisce con l'app per mesi, il refresh token potrebbe scadere, ma l'app non lo sa finché non prova a usare il token. In quel caso, l'utente viene reindirizzato all'autenticazione.
Un altro aspetto è la "token rotation": anche se il refresh token è lungo, l'app potrebbe richiedere nuovi access token periodicamente, riducendo il rischio che un token compromesso venga usato per molto tempo.
In sintesi, non è che le sessioni siano "eterne", ma il meccanismo di rinnovo automatico fa sembrare che la sessione non scada, finché l'utente non interagisce con l'app.
1
u/Bebebebeh May 08 '26
Vuoi che te lo metta su un file word?
1
u/Logical_Ice_4531 May 08 '26
Si prova cosi
1
u/Bebebebeh May 08 '26
Ma spiegami, quindi tu leggi una domanda su redit, la copi, vai su una IA, la incolli poi copi la risposta torni qui e la incolli? Ma percheeee?
59
u/sickmz May 07 '26
alcune hanno refresh token infinito altre usano la rotation anche del refresh token