Antimodèle: ne définir aucun délai d'expiration pour les jetons OAuth

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

Apigee Edge fournit le framework OAuth 2.0 pour sécuriser les API. OAuth2 est l'un des schémas les plus courants d'autorisation et d'authentification basée sur les jetons de norme ouverte et d'autorisation. Il permet aux applications clientes d'accéder aux API pour le compte d'utilisateurs sans que ces derniers aient besoin de divulguer leur nom d'utilisateur et leur mot de passe.

Apigee Edge permet aux développeurs de générer des jetons d'accès et/ou d'actualisation en mettant en œuvre l'un des quatre types d'attributions OAuth2 : identifiants client, mot de passe, implicite, et code d'autorisation - en utilisant la stratégie OAuthv2. Les applications clientes utilisent des jetons d'accès pour utiliser des API sécurisées. Chaque jeton d'accès a son propre délai d'expiration, qui peut être défini dans la stratégie OAuthv2.

Les jetons d'actualisation sont éventuellement fournis avec des jetons d'accès avec certains types de subvention. Les jetons d'actualisation permettent d'obtenir de nouveaux jetons d'accès valides une fois que le jeton d'accès d'origine a expiré ou a été révoqué. Le délai d'expiration des jetons d'actualisation peut également être défini dans la stratégie OAuthv2.

Cet antimodèle est lié à l'antimodèle de définition d'un délai d'expiration long pour les jetons OAuth.

Antimodèle

Si vous ne définissez aucun délai d'expiration pour un jeton d'actualisation dans la stratégie OAuthv2 , les jetons OAuth s'accumulent et l'utilisation de l'espace disque augmente sur les nœuds Cassandra.

L'exemple de stratégie OAuthV2 suivant montre une configuration manquante pour <RefreshTokenExpiresIn> :

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

Dans l'exemple ci-dessus :

• Le jeton d'accès est défini avec un délai d'expiration raisonnablement court de 30 minutes.
• Le délai d'expiration du jeton d'actualisation n'est pas défini.
• Le jeton d'actualisation est conservé indéfiniment dans le datastore (Cassandra), ce qui entraîne une accumulation de données.
• Un jeton d'actualisation généré sans délai d'expiration peut être utilisé indéfiniment pour générer des jetons d'accès.
• Si le trafic vers cette API est de 10 requêtes par seconde, elle peut générer jusqu'à 864 000 jetons par jour.

Impact

• Si le jeton d'actualisation est créé sans délai d'expiration, deux conséquences majeures se produisent :
  • Le jeton d'actualisation peut être utilisé à tout moment dans le futur, peut-être pendant des années, pour obtenir un jeton d'accès token. Cela peut avoir des implications en termes de sécurité.
  • La ligne de Cassandra contenant le jeton d'actualisation ne sera jamais supprimée. Cela entraînera une accumulation de données dans Cassandra.
• Si vous n'utilisez pas le jeton d'actualisation pour obtenir un nouveau jeton d'accès, mais que vous créez un nouveau jeton d'actualisation et un nouveau jeton d'accès, l'ancien jeton d'actualisation restera dans Cassandra. Par conséquent, les jetons d'actualisation continueront de s'accumuler dans Cassandra, ce qui augmentera encore le gonflement, l'utilisation du disque et les compactages plus lourds, et finira par entraîner des latences de lecture/écriture dans Cassandra.

Bonnes pratiques

Utilisez un délai d'expiration suffisamment court pour les jetons d'actualisation et d'accès. Consultez les bonnes pratiques pour définir les délais d'expiration des jetons d'actualisation et d'accès. Assurez-vous de spécifier une configuration d'expiration pour les jetons d'accès et d'actualisation dans la stratégie. Pour en savoir plus sur la configuration des stratégies, consultez la documentation sur la stratégie OauthV2.

Bonnes pratiques spécifiques aux clients Edge for Private Cloud

Cette section décrit les bonnes pratiques spécifiques aux clients Edge for Private Cloud.

Spécifier un délai d'expiration par défaut pour le jeton d'actualisation

Par défaut, si aucun délai d'expiration n'est spécifié pour un jeton d'actualisation dans une configuration de stratégie, Edge crée un jeton d'actualisation sans délai d'expiration. Vous pouvez modifier ce comportement en procédant comme suit :

1. Sur un nœud de processeur de messages, modifiez ou créez le fichier de remplacement de configuration $APIGEE_ROOT/customer/application/message-processor.properties. Assurez-vous que ce fichier est lisible par l'utilisateur apigee.
2. Ajoutez la ligne suivante au fichier :

   conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000

   Cela définira le délai d'expiration par défaut du jeton d'actualisation sur une heure si aucun délai n'est spécifié dans une stratégie. Vous pouvez modifier cette valeur par défaut en fonction des besoins de votre entreprise.
3. Redémarrez le service de processeur de messages :

   apigee-service edge-message-processor restart

4. Répétez les étapes ci-dessus dans tous les nœuds de processeur de messages, un par un.

Bonnes pratiques dans Cassandra

• kms.oauth_20_access_tokens.oauth_20_access_tokens_organization_name_idx#f0f0f0 et
• kms.oauth_20_access_tokens.oauth_20_access_tokens_status_idx

Vous pouvez également réduire gc_grace_seconds dans le tableau kms.oauth_20_access_tokens de la valeur par défaut de 10 jours à une valeur inférieure (par exemple, 3 jours) pour vous assurer que les marqueurs de suppression générés en raison de la suppression des jetons sont purgés plus rapidement du datastore.

Documentation complémentaire

• framework OAuth 2.0
• Sécuriser des API avec OAuth
• Limites du produit Edge