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

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Apigee Edge proporciona el framework de OAuth 2.0 para proteger las APIs. OAuth2 es uno de los esquemas más populares de autorización y autenticación de estándar abierto y basado en tokens y autorización. Permite que las aplicaciones cliente accedan a las APIs 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 - mediante la política de OAuthv2. Las aplicaciones cliente usan tokens de acceso para consumir APIs seguras. Cada token de acceso tiene su propia fecha de vencimiento, que se puede configurar 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. El vencimiento para 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

Si no se establece un tiempo de vencimiento para un token de actualización en la política de OAuthv2 , se produce una acumulación de tokens de OAuth y un mayor uso de espacio en el 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:

• El token de acceso se configura en un tiempo de vencimiento razonable de 30 minutos.
• No se establece el vencimiento del token de actualización.
• El token de actualización persiste en el almacén de datos (Cassandra) para siempre, lo que provoca la acumulación de datos
• Un token de actualización acuñado 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 864,000 tokens por día.

Impacto

• Si el token de actualización se crea sin vencimiento, hay dos consecuencias principales:
  • El token de actualización se puede usar en cualquier momento en el futuro, posiblemente durante años, para obtener un token de acceso token. Esto puede tener implicaciones de 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 anterior permanecerá en Cassandra. Como resultado, los tokens de actualización seguirán acumulándose en Cassandra, lo que aumentará el tamaño, el uso del disco y las compactaciones más pesadas, y, finalmente, provocará latencias de lectura y escritura en Cassandra.

Práctica recomendada

Usa un tiempo de vencimiento adecuadamente bajo para los tokens de actualización y de acceso. Consulta la práctica recomendada para establecer los tiempos de vencimiento de los tokens de actualización y de acceso. Asegúrate de especificar una configuración de vencimiento para el token de 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 nube privada

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

Especifica un vencimiento predeterminado del token de actualización

De forma predeterminada, si no se especifica un vencimiento del token de actualización en una configuración de política, Edge crea un token de actualización sin vencimiento. Puedes anular este comportamiento con 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 tus necesidades empresariales.
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

• 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 a un valor más bajo (como 3 días) para asegurarte de que los marcadores de eliminación generados debido a que se borran los tokens se purguen del almacén de datos más rápido.

Lecturas adicionales

• Marco de trabajo de OAuth 2.0
• Protege las APIs con OAuth
• Límites de productos de Edge