Estás consultando la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de
Apigee Edge.
Apigee proporciona un conjunto de herramientas y políticas que te permiten implementar la autenticación basada en tokens de OAuth 2.0 para proteger tus APIs. OAuth2, descrito en IETF RFC 6749, es el estándar abierto más utilizado para la autenticación y la autorización de APIs. Establece el token como una credencial de formato estándar que las aplicaciones cliente envían a las implementaciones de la API. La implementación de la API puede verificar el token para determinar si el cliente está autorizado a acceder a la API.
Apigee permite a los desarrolladores generar tokens de acceso o de actualización implementando cualquiera de los cuatro tipos de concesión de OAuth2: credenciales de cliente, contraseña, implícito y código de autorización, mediante la política OAuthv2. Además, los desarrolladores de APIs pueden usar Apigee para implementar concesiones personalizadas, incluidas las que siguen el patrón de intercambio de tokens, tal como se describe en el RFC 8693 de IETF. Las aplicaciones cliente usan tokens de acceso para consumir APIs seguras. Cada token de acceso tiene su propio tiempo de vencimiento, que se puede definir en la política de OAuth v2.
Apigee puede generar y devolver un token de actualización junto con el token de acceso con algunos de los tipos de concesión. Un cliente usa un token de actualización para obtener un nuevo token de acceso después de que se revoque o caduque el token de acceso original. El tiempo de caducidad del token de actualización también se puede definir en la política de OAuth v2.
Antipatrón
Si se define una fecha de caducidad larga para un token de acceso o un token de actualización en la política OAuthv2, se amplía el periodo de vulnerabilidad en caso de que se filtre el token, lo que supone un riesgo de seguridad. También puede provocar una acumulación de tokens de OAuth en el almacenamiento persistente, lo que puede provocar una disminución del rendimiento con el tiempo.
Ejemplo 1
En la siguiente política OAuthV2 de ejemplo se muestra un tiempo de caducidad largo de 10 días para los tokens de acceso:
<OAuthV2 name="OAuth-GenerateAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>864000000</ExpiresIn> <!-- 10 days -->
<RefreshTokenExpiresIn>864000000</RefreshTokenExpiresIn> <!-- 10 days -->
<SupportedGrantTypes>
<GrantType>authorization_code</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="true"/>
</OAuthV2>En el ejemplo anterior:
- La duración del token de acceso es de 10 días.
- La duración del token de actualización también es de 10 días.
Impacto
Los tokens de acceso de larga duración suponen un riesgo para la seguridad. En caso de filtración o pérdida de tokens, un token de corta duración caducará de forma natural y dejará de ser útil, mientras que un token de larga duración seguirá concediendo acceso a la API durante un periodo potencialmente prolongado, lo que aumentará el tiempo de vulnerabilidad.
Un token de acceso debe tener una duración breve, probablemente de unos 30 minutos o menos, y esa duración debe ser considerablemente inferior a la del token de actualización.
Ejemplo 2
En el siguiente ejemplo de política OAuthV2 se muestra un tiempo de caducidad largo de 200 días para los tokens de actualización:
<OAuthV2 name="OAuth-GenerateAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
<RefreshTokenExpiresIn>17280000000</RefreshTokenExpiresIn> <!-- 200 days -->
<SupportedGrantTypes>
<GrantType>authorization_code</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="true"/>
</OAuthV2>En el ejemplo anterior:
- El token de acceso se define con un tiempo de vencimiento razonable y breve de 30 minutos.
- El token de actualización se define con un tiempo de caducidad muy largo, de 200 días.
- Si el tráfico a esta API es de 10 solicitudes por segundo, puede generar hasta 864.000 tokens al día.
- Los tokens de actualización caducan al cabo de 200 días y se acumulan en el almacén de datos durante toda su vida útil.
Impacto
Si la duración del token de actualización es larga, el rendimiento puede degradarse con el tiempo, ya que se acumulará un gran número de tokens en el almacén de datos. En Apigee Hybrid, la acumulación excesiva de tokens también puede contribuir al agotamiento del espacio en disco en la capa de persistencia.
Práctica recomendada
Usa un tiempo de vencimiento para los tokens de acceso y de actualización de OAuth que se ajuste a tus requisitos de seguridad específicos para reducir el periodo de vulnerabilidad de los tokens filtrados y evitar la acumulación de tokens en el almacén de datos. Un buen punto de partida para la duración de los tokens de acceso es de 30 minutos, mientras que para la duración de los tokens de actualización es de 24 horas.
Define la fecha de caducidad de los tokens de actualización de forma que sea un múltiplo de la vida útil de los tokens de acceso. Por ejemplo, si defines 30 minutos para el token de acceso, define el tiempo de vida del token de actualización en 24 horas, 7 días o el periodo que sea adecuado para la experiencia de usuario que quieras ofrecer.