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

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

Apigee Edge proporciona el marco de trabajo de OAuth 2.0 para proteger las API. 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 a los desarrolladores generar 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ícito y código de autorización, con la política de OAuthv2. Las aplicaciones cliente usan tokens de acceso para consumir API seguras. Cada token de acceso tiene su propia fecha de vencimiento, que se puede establecer en la política de 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. La hora de vencimiento de los tokens de actualización también se puede establecer en la política de OAuthv2.

Este antipatrón está relacionado con el antipatrón de establecer un tiempo de vencimiento prolongado para los tokens de OAuth.

Antipatrón

No establecer un tiempo de vencimiento para un token de actualización en la política de OAuthv2 genera la acumulación de tokens de OAuth y un mayor uso del espacio en el disco en los nodos de Cassandra.

En la siguiente política de OAuthV2 de ejemplo, 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, sucede 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 persiste en el almacén de datos (Cassandra) para siempre, lo que causa la acumulación de datos.
  • Un token de actualización emitido sin vencimiento se puede usar de forma indefinida para generar tokens de acceso.
  • Si el tráfico a esta API es de 10 solicitudes por segundo, puede generar un máximo de 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, posiblemente durante años, para obtener un token de acceso. Esto puede tener consecuencias en la seguridad.
    • La fila de Cassandra que contiene el token de actualización nunca se borrará. Esto hará que los datos se acumulen en Cassandra.
  • Si no usas el token de actualización para obtener un token de acceso nuevo, sino que creas un token de actualización y un token de acceso nuevos, el token de actualización más antiguo permanecerá en Cassandra. Como resultado, los tokens de actualización seguirán acumulándose en Cassandra, lo que aumentará aún más el sobredimensionamiento, el aumento del uso del disco y las compactaciones más pesadas, y, con el tiempo, causarán latencias de lectura y escritura en Cassandra.

Práctica recomendada

Usa un tiempo de vencimiento apropiado y bajo para los tokens de actualización y de acceso. Consulta las prácticas recomendadas para configurar las fechas de vencimiento de los tokens de acceso y actualización. Asegúrate de especificar una configuración de vencimiento para el acceso y el token de actualización en la política. Consulta la documentación de la política de OAuthV2 para obtener más detalles sobre la configuración de la política.

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

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

Especifica un vencimiento predeterminado para el token de actualización

De forma predeterminada, si no se especifica un vencimiento de token de actualización en una configuración de política, Edge crea un token de actualización sin vencimiento. Puedes anular este comportamiento mediante 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 el usuario apigee pueda leer este archivo.
  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, si no se especifica ninguno en una política, en 1 hora. 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 que esté disponible de forma pública. Apigee continúa lanzando 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 dentro del espacio de claves “kms”. Debes asegurarte de que la estrategia de compactación de este espacio de claves esté configurada 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 la gc_grace_seconds de la tabla kms.oauth_20_access_tokens de los 10 días predeterminados a un valor más bajo (como 3 días) para garantizar que las exclusiones generadas debido a la eliminación de tokens se borren definitivamente del almacén de datos con mayor rapidez.

Lecturas adicionales