Gli amaretti sono più buoni dei biscotti :)

In uno dei miei post precedenti sui problemi con i token JWT, ho parlato di un problema urgente che puoi scoprire qui:

Storia di un problema irrisolvibile con JWT! (Parte 2)

Riassumendo il problema solo per brevità: i poteri di un token JWT non possono essere ridotti quando lo si condivide con altri servizi o entità. Ad esempio, se desideri utilizzare le API di Google e desideri solo che i tuoi script dell'app leggano le tue e-mail ed estraggono alcune informazioni da esse, ma non vuoi che gli script dell'app facciano altro come inviare e-mail o leggere o condividere i tuoi documenti con altri. Abbastanza giusto! Ma se pensi di condividere il tuo token JWT (o il token OAuth) con i tuoi script dell'app, finiresti per dare loro tutti i privilegi che hai! E non lo vogliamo bene...

Quindi la domanda diventa: come evitiamo questo problema in primo luogo?

Come deleghiamo le autorizzazioni utilizzando uno schema in cui c'è un effetto di "attenuazione"?

Pensa per un momento... Riesci a trovare qualcosa che risolva i token JWT? o abbiamo bisogno di qualche altro costrutto per questo?

Hai bisogno di amaretti!

La risposta è: NO, non possiamo riparare i JWT come per questa attività. I token JWT affermano l'autorizzazione ma quando sono coinvolte più parti, in quei casi i JWT non sono adatti, come abbiamo visto nell'esempio sopra!

Allora cosa facciamo?

MACARON! Sì, non scherzo, useremmo gli amaretti. Sono buonissimi e fanno il loro lavoro...

Amaretti sono i costrutti che forniscono delega e attenuazione . Sembra troppo bello per essere vero? C'è ancora di meglio: gli amaretti ti consentono di esprimere anche condizioni di "terze parti"!

Allora, cos'è tutta questa roba gustosa e come può risolvere i miei problemi?

Gli amaretti usano l'HMAC del token che viene delegato e fanno uso di avvertimenti che sono l'asserzione che fa (pensalo come affermazioni JWT).

Quindi l'idea è:

Il server ti invia un amaretto firmandolo utilizzando una chiave in suo possesso. L'HMAC dell'amaretto (usando la chiave di firma) viene aggiunto ad esso, per garantire l'integrità!

Ora, diciamo che voglio delegare i privilegi al mio script dell'app, quello che farei è aggiungere un'altra affermazione, ovvero aggiungo un altro avvertimento all'amaretto che ho e lo firmo usando il valore HMAC dell'amaretto esistente.

In questo modo, è possibile costruire una catena di fiducia con i caveat (che fungono da asserzioni).

Ora, quando un server controlla se le operazioni sono consentite per un determinato utente, controlla l'amaretto, verificando se è tutto corretto, firmando gli avvertimenti macaron e raggiungendo l'ultimo livello. E se va tutto bene, le autorizzazioni necessarie per accedere a un servizio vengono verificate rispetto a tutti i caveat. Se tutto va bene, l'utente o l'entità ottiene l'accesso per eseguire l'attività!

Bello non è vero :)

Conclusione

Questo problema con JWT non può essere risolto affatto! Quindi abbiamo bisogno di qualche altro costrutto per affrontare questo problema e abbiamo visto come gli amaretti affrontano proprio questo problema!

Spero che questo post ti abbia aiutato a imparare qualcosa di interessante. Per me è stata una vera rivelazione sapere che esiste qualcosa del genere! Personalmente mi è piaciuto :)

Potrei fare un post futuro su Macaroons e forse dettagliarlo di più e mostrare alcuni esempi con codice di esempio. Sembra interessante? Fatemi sapere se volete vedere quel post :)

Ti è piaciuto questo post? Fatemi sapere i vostri pensieri nei commenti qui sotto :)

A proposito, se ti piace il mio lavoro e desideri supportarmi, controlla la mia pagina Patreon:

Ci vediamo!
Alla prossima volta, continua a imparare e buon hacking :)