Estoy considerando un caso de uso donde un cliente OAuth2 obtiene un token de acceso para acceder a múltiples servidores de recursos.
Basado en spec , para proteger contra el ataque de redirección de token:
para lidiar con la redirección de token, es importante para la autorización
servidor para incluir la identidad de los destinatarios previstos (el
audiencia), normalmente un solo servidor de recursos (o una lista de recursos
Servidores), en el token.
Esto significa que en nuestro caso de uso, el token de acceso puede tener una lista de URI de audiencia y luego cada servidor de recursos verificará que el token tenga acceso a su recurso.
Sin embargo, de acuerdo con el borrador de la especificación del Indicadores de recursos para OAuth2 , los autores afirman:
Sigo cuestionando el valor de permitir múltiples recursos vs La complejidad funcional y de seguridad que conlleva hacerlo. Escribir el párrafo anterior simplemente subraya esa preocupación. Por lo que sólo anotándolo aquí.
También he notado que los proveedores de administración de identidades, como Auth0 , solo son compatibles con solo los valores de campo de audiencia y en su lugar apuntan a usar una combinación de scope y audience para múltiples servidores de recursos.
Otros proveedores admiten audiencias múltiples.
Entonces ... ¿hay algún problema de seguridad al tener múltiples valores de audiencia?
Me parece que scope y audience tienen diferentes intenciones, por lo que mezclarlas no es necesariamente el enfoque correcto. De acuerdo a :
El alcance, de la Sección 3.3 de OAuth 2.0 [RFC6749], a veces es sobrecargado para transmitir la ubicación o identidad del servidor de recursos, Sin embargo, hacerlo no siempre es factible o deseable. El alcance es por lo general sobre qué acceso se solicita en lugar de dónde el acceso se canjeará (por ejemplo, correo electrónico, usuario: seguir, user_photos, y canales: los leídos son una pequeña muestra de los valores de alcance en uso).
Cualquier pensamiento sobre esto sería apreciado. ¡Gracias!
Nota:
Redirección de token: un atacante usa un token generado para el consumo por un servidor de recursos para obtener acceso a un recurso diferente servidor que cree erróneamente que el token es para él.