Antipatrón: No estableces una hora de vencimiento para los tokens de OAuth

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

Apigee Edge proporciona el framework de OAuth 2.0 para APIs seguras. OAuth2 es uno de los esquemas más populares de autorización y autenticación de estándar abierto y basado en tokens. Permite que las aplicaciones cliente accedan a las API en nombre de los usuarios sin que estos tengan que revelar su nombre de usuario y contraseña.

Apigee Edge permite que los desarrolladores generen tokens de acceso o actualización mediante la implementación de cualquiera de los cuatro tipos de otorgamiento de OAuth2. credenciales de cliente, contraseña, implícita y código de autorización - con la política OAuthv2. Las aplicaciones cliente usan tokens de acceso para consumir API seguras. Cada token de acceso tiene su propio vencimiento que se puede configurar en la política OAuthv2.

De forma opcional, los tokens de actualización se emiten junto con los tokens de acceso con algunos tipos de otorgamiento. Los tokens de actualización se usan para obtener nuevos tokens de acceso válidos después de que el token de acceso original venza o se revoque. El tiempo de vencimiento de los tokens de actualización también se puede establecer en la política OAuthv2.

Este antipatrón se relaciona con el antipatrón de un tiempo de caducidad prolongado para tokens de OAuth.

Antipatrón

Establecer no una hora de vencimiento para un token de actualización en la política OAuthv2 conduce a la acumulación de tokens de OAuth y a un mayor uso del espacio en disco en los nodos de Cassandra.

En el siguiente ejemplo de política de OAuthV2, se muestra una configuración faltante para <RefreshTokenExpiresIn>: 

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <!--<RefreshTokenExpiresIn> is missing -->
    <SupportedGrantTypes>
      <GrantType>password</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

En el ejemplo anterior, se muestra lo siguiente:

  • El token de acceso se configura con un tiempo de vencimiento razonablemente bajo de 30 minutos.
  • No se estableció el vencimiento del token de actualización.
  • El token de actualización permanece en el almacén de datos (Cassandra) para siempre, lo que genera datos la acumulación.
  • Un token de actualización creado sin vencimiento se puede usar de manera indefinida para generar tokens de acceso.
  • Si el tráfico a esta API es de 10 solicitudes por segundo, se pueden generar hasta 864,000 tokens. en un día.

Impacto

  • Si el token de actualización se crea sin vencimiento, hay dos consecuencias importantes:
    • El token de actualización se puede usar en cualquier momento futuro, posiblemente durante años, para obtener un acceso. token. Esto puede tener implicaciones de seguridad.
    • Nunca se borrará la fila en Cassandra que contiene el token de actualización. Esto hará que los datos se acumulen en Cassandra.
  • Si no usas el token de actualización para obtener un token de acceso nuevo, pero, en su lugar, crea un token de actualización y un token de acceso nuevos el token de actualización más antiguo permanecerá en Cassandra. Como resultado, actualiza la página seguirán acumulándose en Cassandra, lo que aumentará la sobrecarga mayor uso del disco y compactaciones más pesadas que, con el tiempo, harán que las operaciones de lectura/escritura latencias en Cassandra.

Práctica recomendada

Usa un tiempo de vencimiento apropiado para los tokens de acceso y actualización. Consulta práctica recomendada para configurar el vencimiento los horarios de actualización y los tokens de acceso. Asegúrate de especificar una configuración de vencimiento para ambos accesos y el token de actualización en la política. Consulta las Documentación de la política de OAuthV2 para obtener más detalles sobre la configuración de políticas.

Prácticas recomendadas específicas para los clientes de Edge para la nube privada

En esta sección, se describen las prácticas recomendadas específicas para los clientes de Edge para la nube privada.

Cómo especificar un vencimiento predeterminado del token de actualización

De forma predeterminada, si no se especifica un vencimiento del token de actualización en la configuración de una política, Edge crea un token de actualización sin vencimiento. Puedes anular este comportamiento el siguiente procedimiento:

  1. En un nodo del procesador de mensajes, edita o crea el archivo de anulación de configuración $APIGEE_ROOT/customer/application/message-processor.properties Asegúrate de que este archivo sea lo puede leer el usuario apigee.
  2. Agrega la siguiente línea al archivo: 
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
     Esto establecerá el vencimiento predeterminado del token de actualización en 1 hora si no se especifica ninguno en una política. Puedes cambiar este valor predeterminado según las necesidades de tu empresa.
  3. Reinicia el servicio del procesador de mensajes: 
    apigee-service edge-message-processor restart
  4. Repite los pasos anteriores en todos los nodos del procesador de mensajes uno por uno.

Prácticas recomendadas en Cassandra

Intenta actualizar a la versión más reciente de Apigee disponible de forma pública. Apigee continúa para lanzar correcciones y mejoras que continúan optimizando y optimizando la administración de tokens dentro de Apigee. En Apigee, los tokens de acceso y actualización se almacenan en Cassandra en el espacio de claves “kms”. Debes asegurarte de que la estrategia de compactación se establece en LeveledCompactionStrategy. Debes comprobar que los siguientes índices no estén presentes:
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_organization_name_idx#f0f0f0 y
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_status_idx

También puedes reducir gc_grace_seconds en la tabla kms.oauth_20_access_tokens de los 10 días predeterminados (por ejemplo, 3 días) para garantizar que las tombstones generadas debido a que los tokens se borran se y se eliminen del almacén de datos más rápido.

Lecturas adicionales