La respuesta corta es que no está definido. Si desea una biblioteca que admita ambas, asegúrese de que indique explícitamente que admite tanto OAuth 2 como OIDC.
Si dibujara un diagrama de Venn, OAuth 2 y OIDC se intersecan entre sí, pero OAuth 2 también define algunos flujos que OIDC no extiende, y OIDC agrega un flujo que no está en OAuth 2.
Flujos de OAuth 2 :
- Concesión de código de autorización
- Subvención implícita
- concesión de credenciales de contraseña del propietario del recurso
- Subvención de credenciales de cliente
Flujos de OIDC :
- Concesión de código de autorización
- Subvención implícita
- híbrido
La especificación OIDC amplía explícitamente el código de autorización de OAuth 2 y los flujos implícitos, pero no dice nada sobre los demás. Por lo tanto, una implementación determinada de OIDC puede soportar total o parcialmente o no los flujos de OAuth 2 restantes. Quiero decir parcialmente, solo devuelve el token de acceso según OAuth 2, pero no el token de ID.
Entonces, ¿por qué OIDC no cubre explícitamente todos los flujos de OAuth 2? Esto es lo que pienso:
- Credencial de contraseña del propietario del recurso Otorgar. Este flujo anula las características de seguridad introducidas por la concesión del código de autorización de OAuth 2. Desde una perspectiva de seguridad, manténgase alejado de este flujo.
- Subvención de credenciales de cliente. Un ejemplo de este escenario es la comunicación de servicio a servicio, que podría resolverse con PKI; no necesita el token de identificación introducido por OIDC.