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

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Apigee Edge fournit le framework OAuth 2.0 pour des API sécurisées. OAuth2 est l'un des schémas les plus courants d'autorisation et d'authentification basée sur les jetons de norme ouverte. 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 implémentant l'un des les quatre types d'octrois OAuth2 : identifiants client mot de passe, implicit ; code d'autorisation à l'aide de la règle OAuthv2. Les applications clientes utilisent des jetons d'accès pour utiliser des API sécurisées. Chaque jeton d'accès a sa propre date d'expiration qui peut être définie dans la règle 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 règle OAuthv2.

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

Antimodèle

Définir l'absence de délai d'expiration pour un jeton d'actualisation dans la règle OAuthv2 entraîne une accumulation de jetons OAuth et une augmentation de l'utilisation de l'espace disque sur les nœuds Cassandra.

L'exemple de règle 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 bas de 30 minutes.
• Le délai d'expiration du jeton d'actualisation n'est pas défini.
• Le jeton d'actualisation persiste indéfiniment dans le data store (Cassandra), ce qui entraîne des problèmes de données et l'accumulation de données.
• Un jeton d'actualisation généré sans 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 dans une journée.

Impact

• Si le jeton d'actualisation est créé sans expiration, cela a deux conséquences majeures: <ph type="x-smartling-placeholder">
  </ph>
  • Vous pouvez utiliser le jeton d'actualisation à tout moment à l'avenir, éventuellement pendant des années, pour obtenir un accès. à partir d'un jeton d'accès. Cela peut avoir des conséquences sur la sécurité.
  • La ligne Cassandra contenant le jeton d'actualisation ne sera jamais supprimée. Cela entraîne l'accumulation de données dans Cassandra.
• Si vous n'utilisez pas le jeton d'actualisation pour obtenir un nouveau jeton d'accès, mais de créer à la place un jeton d'actualisation et un jeton d'accès actualisés. l'ancien jeton d'actualisation reste dans Cassandra. Par conséquent, actualisez la page les jetons continuent de s'accumuler dans Cassandra, ce qui augmente une utilisation accrue du disque et des compactages plus lourds, et finira par provoquer des opérations de lecture/écriture les latences dans Cassandra.

Bonne pratique

Utilisez un délai d'expiration suffisamment bas pour les jetons d'actualisation et d'accès. Voir bonnes pratiques pour définir un délai d'expiration les délais d'actualisation et les jetons d'accès. Veillez à spécifier une configuration d'expiration pour les deux accès et actualiser le jeton dans la stratégie. Consultez le Documentation sur la règle OAuthV2 pour en savoir plus sur la configuration des règles.

Bonnes pratiques spécifiques pour les clients Edge pour Private Cloud

Cette section décrit les bonnes pratiques spécifiquement pour les clients Edge pour Private Cloud.

Spécifier l'expiration par défaut du jeton d'actualisation

Par défaut, si un délai d'expiration de jeton d'actualisation n'est pas spécifié dans une configuration de stratégie, Edge crée un jeton d'actualisation sans expiration. Vous pouvez ignorer ce comportement la procédure suivante:

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

   Si aucune règle n'est spécifiée, le délai d'expiration par défaut du jeton d'actualisation est défini sur une heure. Vous pouvez modifier cette valeur par défaut en fonction des besoins de votre entreprise.
3. Redémarrez le service de traitement des messages:

   apigee-service edge-message-processor restart

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

Bonnes pratiques dans Cassandra

</ph>
• 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 10 jours par défaut (3 jours, par exemple) pour s'assurer que les tombstones générés en raison de la suppression de jetons sont du data store plus rapidement.

Documentation complémentaire

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