Choisir un autorisateur d'API Gateway

Utiliser la sécurité AWS pour les développeurs

Rahul Singh

Technical Product Manager

Vérifié avant l'exécution de votre code

Un appelant passe par l'autorisateur d'API Gateway avant d'atteindre votre code, et un appelant rejeté reçoit un 401.

Réussite : la requête atteint votre code

Échec : 401 non autorisé, votre code ne s'exécute pas

Qui fait la vérification

Trois autorisateurs possibles

Auth IAM (AWS_IAM) : AWS vérifie une signature

Une pile verticale sur un axe allant d'AWS qui fait la vérification jusqu'à vous qui la faites. Seule la première carte est remplie : Auth IAM, où AWS vérifie une signature.

Qui fait la vérification

Trois autorisateurs possibles

Auth IAM (AWS_IAM) : AWS vérifie une signature
Autorisateur Cognito (COGNITO_USER_POOLS) : AWS valide un jeton
- Signature, iss, aud, exp

La même pile verticale avec deux cartes remplies : Auth IAM, où AWS vérifie une signature, et un autorisateur Cognito, où AWS valide un jeton.

Qui fait la vérification

Trois autorisateurs possibles

Auth IAM (AWS_IAM) : AWS vérifie une signature
Autorisateur Cognito (COGNITO_USER_POOLS) : AWS valide un jeton
- Signature, iss, aud, exp
Autorisateur Lambda : votre fonction retourne allow ou deny
- Pour des jetons non Cognito

Trois autorisateurs classés de AWS qui vérifie jusqu'à vous qui vérifiez : Auth IAM où AWS vérifie une signature, un autorisateur Cognito où AWS valide un jeton, et un autorisateur Lambda où vous écrivez la vérification.

Faites correspondre la porte à l'appelant

L'appelant décide

Service interne : possède déjà des identifiants AWS

La première de trois lignes appelant→autorisateur : un service interne associé à Auth IAM.

Faites correspondre la porte à l'appelant

L'appelant décide

Service interne : possède déjà des identifiants AWS
Utilisateur d'appli : présente un jeton Cognito

Deux des trois lignes appelant→autorisateur : un service interne associé à Auth IAM, et un utilisateur d'appli associé à un autorisateur Cognito.

Faites correspondre la porte à l'appelant

L'appelant décide

Service interne : possède déjà des identifiants AWS
Utilisateur d'appli : présente un jeton Cognito
Appli partenaire : apporte sa propre logique d'autorisation

Trois appelants associés à l'autorisateur requis : un service interne à Auth IAM, un utilisateur d'appli à un autorisateur Cognito et une appli partenaire à un autorisateur Lambda.

Attention au type d'API

API REST

Les trois autorisateurs, plus des stratégies de ressources
Clés d'API, limitation par client, validation des requêtes, WAF

Une carte de comparaison pour une API REST, cochant Auth IAM, un autorisateur de groupe d'utilisateurs Cognito, un autorisateur Lambda et une stratégie de ressources. La carte API HTTP à côté n'est pas encore remplie.

Attention au type d'API

API REST

Les trois autorisateurs, plus des stratégies de ressources
Clés d'API, limitation par client, validation des requêtes, WAF

API HTTP

Autorisateur JWT, n'importe quel émetteur OIDC
Aucune stratégie de ressources ; moins coûteuse et plus rapide

Deux cartes comparant les autorisateurs pris en charge : une API REST ajoute des stratégies de ressources, tandis qu'une API HTTP remplace l'autorisateur Cognito par un autorisateur JWT et n'a pas de stratégies de ressources.

L'autorisateur se souvient

Mis en cache pour gagner du temps

Premier appel : l'autorisateur s'exécute
Appels suivants : on lit la réponse en cache

Le premier appel exécute l'autorisateur et écrit un allow dans un cache avec une durée de vie ; un appel ultérieur lit ce allow du cache sans relancer l'autorisateur.

L'autorisateur se souvient

Mis en cache pour gagner du temps

Premier appel : l'autorisateur s'exécute
Appels suivants : on lit la réponse en cache

Durée de vie du cache (TTL)

authorizerResultTtlInSeconds : 300 s par défaut, 3600 s max
Zéro désactive la mise en cache

Le premier appel exécute l'autorisateur et écrit un allow dans un cache avec une durée de vie ; un appel ultérieur lit ce allow du cache sans relancer l'autorisateur.

Un allow en cache peut survivre à sa permission

Une chronologie à deux voies. La voie des permissions passe de valide à révoquée au point de révocation, tandis que la voie du allow en cache indique encore allow après ce point, avec la fenêtre suivant la révocation ombrée.

Au moment de la révocation

Permission : révoquée immédiatement
Allow en cache : accorde encore l'accès

Un allow en cache peut survivre à sa permission

La même chronologie à deux voies, avec la fenêtre entre la révocation et l'expiration du TTL ombrée et indiquée toujours autorisée : la permission est révoquée mais l'allow en cache continue d'accorder l'accès.

La fenêtre intermédiaire

Permission retirée, le cache n'est pas informé
L'accès dure jusqu'à l'expiration du TTL

Un allow en cache peut survivre à sa permission

La même chronologie à deux voies, avec une flèche sur la fenêtre ombrée montrant qu'un TTL plus court devance l'expiration et réduit la période où une permission révoquée accorde encore l'accès.

Contrôlez cette fenêtre

TTL court quand la révocation doit être rapide
TTL 0 sur les routes les plus sensibles

Un appelant contourne la porte d'entrée

Un tiers à l'intérieur de votre compte

Endosse un rôle que vous avez créé
Vous lui remettez l'ARN du rôle

Un fournisseur de surveillance se trouve entre deux cases clients au-dessus et votre rôle en dessous. Votre case remet l'ARN de son rôle au fournisseur, qui endosse votre rôle. La deuxième case client est grisée et pas encore incluse.

Un appelant contourne la porte d'entrée

Un tiers à l'intérieur de votre compte

Endosse un rôle que vous avez créé
Vous lui remettez l'ARN du rôle

L'ARN du rôle n'est pas un secret

Le problème du deputy confus

La deuxième case client est maintenant active en rouge et remet l'ARN de votre rôle comme si c'était le sien. Deux flèches descendent du fournisseur vers votre rôle, un appel par client, et rien ne les distingue.

Un appelant contourne la porte d'entrée

Un tiers à l'intérieur de votre compte

Endosse un rôle que vous avez créé
Vous lui remettez l'ARN du rôle

L'ARN du rôle n'est pas un secret

Le problème du deputy confus

Correctif : sts:ExternalId

Le fournisseur en génère un par client
Votre stratégie d'approbation exige la correspondance

Votre rôle impose maintenant que l'identifiant externe soit égal à 12345. L'appel portant 12345 atteint le rôle, et l'appel portant 99999 est bloqué par une croix rouge avant d'y parvenir.

Passons à la pratique !

Utiliser la sécurité AWS pour les développeurs