Un uso improprio di OAuth2 è un protocollo di autenticazione rigoroso. OpenID Connect risolve questo problema estendendo OAuth2 per includere id_token . Implementare i client per OAuth2 e OpenID Connect è un progetto mostruoso. Il fatto che access_token sia opaco lo rende non interoperabile tra le implementazioni. Inoltre, l'implementazione corretta di client e server OAuth2 e OpenID Connect è molto difficile da ottenere.
Come esercizio, stavo sognando una nuova specifica. Stavo pensando di avere un singolo JWT (lo chiameremo auth_token per ora) che funge da% di OAuth% co_de, ma contiene dati utente simili a OpenID Connect access_token . La rivendicazione id_token includerebbe sia aud che client_id , quindi può essere letta da entrambe le parti. Qualsiasi dato sensibile che necessitava di essere crittografato potrebbe andare in una dichiarazione di resource server (cioè l'intero JWT non sarà crittografato, solo i dati in tale affermazione). La nuova specifica offrirà tipi di sovvenzioni simili a OAuth2 per creare questo encrypted_data .
Si spera che ciò comporti sia l'autorizzazione delegata che l'autenticazione introducendo anche l'interoperabilità introducendo alcune dichiarazioni standard per i dati dell'utente, ala auth_token . Ovviamente, un MOLTO più pensiero avrebbe bisogno di entrare in questo per renderlo una vera spec. Quali sono gli svantaggi di questo progetto generale?