Un mal uso común de OAuth2 es como un protocolo de autenticación estricto. OpenID Connect soluciona esto extendiendo OAuth2 para incluir un id_token . La implementación de clientes para OAuth2 y OpenID Connect es un proyecto monstruoso. El hecho de que access_token sea opaco lo hace no interoperable entre las implementaciones. Además, implementar los servidores y clientes OAuth2 y OpenID Connect adecuados es muy difícil de lograr.
Como ejercicio, estaba soñando con una nueva especificación. Estaba pensando en tener un solo JWT (lo llamaremos auth_token por ahora) que actúa como un OAuth access_token , pero contiene datos de usuario similares a un OpenID Connect id_token . La reclamación de aud incluiría tanto el client_id como el resource server , por lo que ambas partes pueden leerlo. Cualquier información confidencial que deba cifrarse podría incluirse en una reclamación encrypted_data (es decir, no se cifrará todo el JWT, solo los datos de esa reclamación). La nueva especificación ofrecería tipos de concesión similares a OAuth2 para crear este auth_token .
Con suerte, esto lograría tanto la autorización delegada como la autenticación, al mismo tiempo que introducirá la interoperabilidad al introducir algunos reclamos estándar para los datos del usuario, ala id_token . Obviamente, un MUCHO más pensamiento tendría que entrar en esto para que sea una especificación real. ¿Cuáles son los inconvenientes de este diseño general?