Ad esempio, diamo un'occhiata a come funziona l'autenticazione con Kubernetes :
Inparticolare,concentriamocisuciòchefailserverapi.Perautenticarelarichiesta,è:
Ci deve essere più di questo! Il problema dei provider OIDC è che distribuiranno token con firme valide a chiunque. Ad esempio, supponiamo di voler utilizzare Google come provider di identità. Se l'unico requisito era che la firma JWT fosse valida, un utente malintenzionato potrebbe configurare un sito che mi piacerebbe, ad esempio con immagini di gatti divertenti. Ad un certo punto visito il sito e accesso, e il bingo, l'attaccante ha un JWT di identità con una firma valida e il mio nome su di esso. Sarebbe piuttosto brutto se il proprietario di funnycatpictures.com potesse ora accedere al server API di Kubernetes sotto il mio nome.
Quindi, in particolare quali sono i vincoli che impediscono questo attacco?
La mia comprensione è che la rivendicazione aud (pubblico) nel JWT è parte di essa: Kubernetes deve accettare il token solo se aud contiene il suo ID client OAuth. Questo dovrebbe significare che i token rilasciati ad altri client OAuth (come il divertente sito di foto di gatti) non saranno accettati perché avranno il aud sbagliato.
Tuttavia, sembra esserci un modo per aggirare questo con il flusso di concessione implicito, che non richiede un segreto client OAuth. In quanto tale, funnycatpictures.com potrebbe utilizzare il flusso implicito ma con l'id del client Kubernetes, ottenendo così token con il aud corretto che sarebbe accettato dal server API di Kubernetes.
Che cosa impedisce un simile attacco?