Token di accesso JWT e token di aggiornamento

Questa è una situazione abbastanza comune in cui ti trovi in cui è una buona cosa in quanto significa che la soluzione è ben nota, discussa e testata.

1. Is a simple signature verification by App2 is enough? Or there is a need that it sends the token to App1 for verification (there is a white list of public keys for App2) ?

Corretto, una verifica della firma "semplice" è tutto ciò che deve fare App2 per convalidare il token. Ciò garantirà a.) Il token è stato distribuito da App1 eb). Le attestazioni (coppie chiave-valore) nel token non sono state manomesse.

2. I'm considering to add an expiration date for 30 mins, how should I handle refresh token at the client-side ?

Questo dipende più dalle preferenze personali, ma non mi piacciono i token di aggiornamento. I token di aggiornamento implicano una data di scadenza futura lontana (vale a dire un paio di giorni o una settimana) e possono essere molto dannosi se vengono rubati. Inoltre, secondo la mia esperienza, non esiste un modo veramente valido per memorizzare un segreto sul lato client. I cookie sono insicuri e non credo che i DB lato client siano molto migliori. È possibile crittografarlo con la password dell'utente, ma ciò richiede che l'utente re-digiti la password che sconfigge comunque lo scopo del token di aggiornamento, giusto? Quindi eviterei di aggiornare i token, se possibile.

3. Instead of generation refresh tokens, is it secure to say that the access token is one-time only and App2 creates a session on the server-side (using the data in the token)?

Non vedo difetti in questo piano, penso che sia molto più sicuro che affidarsi a un token di aggiornamento. L'unica avvertenza qui è quella di garantire la possibilità di annullare un token di accesso su App1. Per altre parole, se eseguo l'autenticazione con App1, ottieni il mio token, poi vieni su App2, autentichi e ottieni il mio ID di sessione, sono felice. Ma un utente malintenzionato potrebbe rubare il mio token dal mio browser cookie. L'utente malintenzionato può utilizzare questo token per andare e ottenere la propria sessione con le mie credenziali su App2 a condizione che il token non sia ancora scaduto. Pertanto, App1 e App2 dovrebbero essere in grado di comunicare in questo scenario. App2 verifica che App1 affermi che il token non è ancora stato utilizzato. App2 lo utilizza, quindi indica a App1 che è stato utilizzato, annulla il token in modo che non possa essere riutilizzato in future richieste per generare un altro ID di sessione.

Come puoi vedere, diventa molto più complicato. Ma, se non lo fai, non utilizzi davvero gettoni una tantum. Un'alternativa potrebbe essere la scadenza del token MOLTO breve (ovvero cinque minuti o meno), tempo sufficiente per la reindirizzamento e l'autenticazione dell'utente con App2 e ottenere l'ID di sessione per l'autenticazione continua. Questa potrebbe essere la via più semplice, ma in realtà dipende dal livello di sicurezza che desideri raggiungere qui.

In ogni caso, l'ID sessione è un'idea intelligente. Ridurrà probabilmente il carico sul tuo server App2 in quanto non dovrà continuamente ricontrollare le firme dei token per ogni richiesta.

Come sviluppatore

A meno che la tua APP 1 non sia costruita per essere un servizio di federazione, non dovresti estendere APP1 per fungere da servizio di federazione. Questo è solo un cattivo design del software.

Se APP2 manca di autenticazione e autorizzazioni, dovresti, logicamente, aggiungerlo nell'applicazione. Può essere un metodo SSO ma assicurarsi che si autentichi con un servizio progettato per l'autenticazione / le autorizzazioni.

Se APP1 e APP2 non hanno nulla a che fare l'uno con l'altro (che suona come) NON CREA UNA DIPENDENZA MEDIANTE AUTENTICAZIONE.

Come un professionista della sicurezza

Per rispondere alle tue domande:

1. Questo dipende dai rischi e dall'importanza di queste applicazioni per l'organizzazione. Potresti voler rileggere su JWT. Per verificare un token, hai bisogno del segreto, e nel tuo progetto APP1 ce l'ha, e devi averlo anche su APP2 (esponendo più rischi) o fare affidamento su APP1 per verificare il token a quale punto devi chiedere te stesso "Perché l'APP 1 dovrebbe sapere se il token per l'APP 2 è valido?" La risposta è perché hai creato una dipendenza non necessaria per APP 1 come responsabile della sicurezza di APP 2.
2. Per la natura dei token, non li gestisci lato client, se un token non viene aggiornato scade, non va bene, dovresti negarlo. Un token di aggiornamento viene utilizzato per generare un nuovo token di autenticazione una volta scaduta la scadenza. Un token di aggiornamento di 30 minuti significa che dopo 30 minuti è necessario eseguire nuovamente la re-autenticazione. Se quello era il tuo obiettivo, allora non avere nessun token di aggiornamento e 30 minuti di autenticazione.
3. Lo scopo di un sistema token è quello di rimuovere lo stato dall'applicazione. Se stai andando a fare sessioni, allora fai sessioni e ignori i token. Se si desidera fare password One-Time, per l'autenticazione APP 2, piuttosto che fare OTP, è orribile per entrambi, perché si hanno tutti i rischi di entrambi e nessuna buona ragione per entrambi. Vorrei leggere su sessioni vs autenticazione token.

La mia opinione su questo sulla base della tua domanda - Sarà una gestione della sicurezza, gestione IT, e l'incubo Dev Management hanno un'app indipendente che si basa su un'altra app indipendente per i servizi di autenticazione.

Sono sicuro che c'è di più nella storia, ma se dovessi prendere decisioni su questo argomento, ci sarebbe un sacco di "mi spiegheresti perché questo ha senso?" Commenti.