Autorisation : IAM, autoriseurs Lambda et Cognito
Sécurisez les points de terminaison d’API avec des signatures IAM SigV4, des autoriseurs Lambda personnalisés ou des autoriseurs de groupes d’utilisateurs Amazon Cognito.
Autorisation : IAM, autoriseurs Lambda et Cognito est une leçon AWS Solutions Architect gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage AWS Solutions Architect, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours AWS Solutions Architect comprend 4 leçons au total.
Pourquoi l’autorisation des API est importante
Sans contrôles d’autorisation, n’importe quel client Internet pourrait appeler les points de terminaison de votre API Gateway et accéder aux données ou les modifier. API Gateway fournit trois mécanismes d’autorisation natifs : IAM (SigV4), les autorisateurs Lambda et les autorisateurs de groupes d’utilisateurs Amazon Cognito. Chaque mécanisme répond à des besoins différents : IAM pour les appels de service à service AWS, les autorisateurs Lambda pour une authentification personnalisée fondée sur un jeton ou une requête, et Cognito pour l’authentification des utilisateurs web ou mobiles.
Autorisation IAM avec SigV4
L’autorisation IAM exige que les appelants signent les requêtes à l’aide de la signature AWS version 4 (SigV4). L’appelant doit disposer d’identifiants AWS (clé d’accès et clé secrète, ou identifiants temporaires fournis par STS), et la politique IAM doit autoriser execute-api:Invoke sur l’ARN de l’API. Cette solution est idéale pour les appels de machine à machine (de serveur à serveur) au sein d’AWS : Lambda appelant une autre API, EC2 appelant une API interne ou accès à un service entre comptes. Les clients de navigateur ne peuvent pas utiliser SigV4 facilement.
# IAM policy to allow invoking a specific API endpoint
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Action': 'execute-api:Invoke',
'Resource': 'arn:aws:execute-api:us-east-1:123456789012:abc123/prod/GET/orders'
}]
}Autorisateurs Lambda : fondés sur un jeton
Un autorisateur Lambda (anciennement autorisateur personnalisé) est une fonction Lambda que vous écrivez et qu’API Gateway invoque avant d’appeler l’intégration du service principal. Pour les autorisateurs fondés sur un jeton, API Gateway extrait un jeton (JWT, OAuth, clé d’API) de l’en-tête Authorization et le transmet à votre fonction Lambda. Votre fonction Lambda valide le jeton (par exemple, en vérifiant la signature JWT à l’aide d’une clé publique ou en appelant un fournisseur d’identité tiers), puis renvoie un document de politique IAM qui autorise ou refuse la requête.
def lambda_handler(event, context):
token = event['authorizationToken']
# Validate token (JWT verification, introspect OAuth, etc.)
if is_valid_token(token):
return {
'principalId': 'user123',
'policyDocument': {
'Version': '2012-10-17',
'Statement': [{'Effect': 'Allow', 'Action': 'execute-api:Invoke',
'Resource': event['methodArn']}]
},
'context': {'userId': 'user123', 'role': 'admin'}
}
raise Exception('Unauthorized')Autorisateurs Lambda : fondés sur la requête
Pour les autorisateurs Lambda fondés sur la requête, API Gateway transmet à votre fonction Lambda l’intégralité du contexte de la requête (en-têtes, chaînes de requête, variables d’étape et paramètres de chemin), et pas seulement un jeton. Cette approche est utile lorsque l’autorisation dépend de plusieurs attributs de la requête : listes d’adresses IP autorisées, combinaisons d’en-têtes ou vérifications de l’authentification multifacteur. Les autorisateurs fondés sur la requête sont pris en charge par REST API et HTTP API.
Mise en cache des autorisateurs Lambda
Appeler un autorisateur Lambda pour chaque requête d’API ajoute de la latence et des coûts. Activez la mise en cache du résultat de l’autorisateur : mettez en cache la politique IAM renvoyée par l’autorisateur pendant une durée TTL configurable (0 à 3600 secondes), en utilisant la valeur du jeton comme clé. Les requêtes suivantes utilisant le même jeton ignorent l’invocation Lambda et utilisent la politique mise en cache. Définissez la TTL en fonction de la durée d’expiration de votre jeton : si un jeton est valide pendant 1 heure, mettez le résultat de l’autorisateur en cache pendant la même durée. La mise en cache est disponible dans REST API ; les autorisateurs JWT de HTTP API disposent d’une mise en cache intégrée.
Autorisateur de groupe d’utilisateurs Amazon Cognito
Les autorisateurs de groupes d’utilisateurs Cognito valident directement dans API Gateway les JWT émis par Cognito, sans fonction Lambda. Lorsqu’un utilisateur s’authentifie via Cognito (par l’interface utilisateur hébergée, le SDK ou un fournisseur d’identité fédéré), Cognito émet un jeton d’ID ou un jeton d’accès. Le client inclut ce jeton dans l’en-tête Authorization. API Gateway vérifie la signature et l’expiration du jeton auprès du groupe d’utilisateurs Cognito. Si le jeton est valide, la requête continue ; sinon, API Gateway renvoie 401.
aws apigateway create-authorizer \
--rest-api-id 'abc123' \
--name 'CognitoAuthorizer' \
--type COGNITO_USER_POOLS \
--provider-arns 'arn:aws:cognito-idp:us-east-1:123456789012:userpool/us-east-1_XXXXXXX' \
--identity-source 'method.request.header.Authorization'Autorisateur JWT dans HTTP API
HTTP API prend nativement en charge les autorisateurs JWT, sans Lambda. Vous indiquez l’URL de l’émetteur JWT (Cognito, Auth0, Okta) et l’audience, puis API Gateway valide automatiquement les JWT. Il s’agit essentiellement d’un autorisateur de groupe d’utilisateurs Cognito, mais cette fonctionnalité fonctionne également avec tout fournisseur OIDC conforme aux normes. La validation du jeton (signature, expiration et audience) est effectuée en interne par API Gateway : la latence est inférieure à celle des autorisateurs Lambda et aucun coût Lambda n’est engendré.
aws apigatewayv2 create-authorizer \
--api-id 'abc123' \
--authorizer-type JWT \
--name 'JWTAuthorizer' \
--identity-source '$request.header.Authorization' \
--jwt-configuration '{
"Issuer": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_XXXXXXX",
"Audience": ["your-client-id"]
}'Groupes d’identités Cognito ou groupes d’utilisateurs
Pour l’autorisation des API, utilisez les groupes d’utilisateurs Cognito : ils gèrent l’authentification des utilisateurs et émettent des JWT. Les groupes d’identités Cognito (identités fédérées) sont différents : ils échangent des jetons tiers (provenant de groupes d’utilisateurs, de connexions sociales ou de SAML) contre des identifiants AWS temporaires (via STS AssumeRoleWithWebIdentity). Les groupes d’identités sont utilisés lorsque votre application doit accéder directement aux services AWS (S3, DynamoDB) depuis le client. Pour l’authentification d’API Gateway, les JWT des groupes d’utilisateurs sont le bon choix ; les identifiants des groupes d’identités servent aux appels directs au SDK AWS depuis un navigateur ou un appareil mobile.
Politiques de ressources dans API Gateway
REST API prend en charge les politiques de ressources : des politiques JSON associées à l’API qui contrôlent l’accès en fonction de l’adresse IP, du point de terminaison VPC, du compte source ou de l’ARN. Utilisez-les pour autoriser uniquement certaines plages d’adresses IP à appeler votre API, limiter l’accès aux requêtes provenant d’un point de terminaison VPC précis (API privée) ou autoriser les invocations entre comptes. Les politiques de ressources fonctionnent en complément des autorisateurs au niveau des méthodes : les deux doivent autoriser la requête pour que celle-ci aboutisse.
# Allow only specific IP range to call the API
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': '*',
'Action': 'execute-api:Invoke',
'Resource': 'arn:aws:execute-api:us-east-1:123456789012:abc123/*',
'Condition': {'IpAddress': {'aws:SourceIp': '203.0.113.0/24'}}
}]
}Authentification TLS mutuelle
La mutualité TLS (mTLS) exige que le client et le serveur présentent tous deux des certificats pendant la négociation TLS. API Gateway prend en charge mTLS pour REST API et HTTP API lorsque des noms de domaine personnalisés sont configurés. Les clients doivent présenter un certificat valide signé par une autorité de certification (CA) que vous téléversez dans un magasin de confiance sur S3. mTLS est utilisée dans les services financiers, pour l’authentification des appareils IoT et dans les intégrations B2B lorsque l’identité du client doit être vérifiée de manière renforcée au-delà de l’authentification par jeton.
Choisir le type d’autorisateur approprié
Choix de l’autorisateur pour l’examen SAA-C03 : IAM (SigV4) → appels de service à service AWS au sein d’un même compte ou entre comptes ; groupe d’utilisateurs Cognito → utilisateurs d’applications web ou mobiles authentifiés via Cognito ; autorisateur Lambda → logique d’authentification personnalisée (fournisseurs d’identité tiers, anciens formats de jeton, introspection OAuth, combinaison IP et jeton) ; autorisateur JWT (HTTP API) → jetons OIDC/OAuth2 avec tout fournisseur conforme aux normes, à un coût inférieur à celui des autorisateurs Lambda. Aucun autorisateur → API publique.
Vérification rapide
Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.
Récapitulatif de la leçon
Dans cette leçon, vous avez appris que l’autorisation IAM (SigV4) est destinée aux appels de service à service utilisant des identifiants AWS ; que les autorisateurs de groupes d’utilisateurs Cognito valident nativement les JWT émis par Cognito pour les applications web et mobiles ; et que les autorisateurs Lambda permettent de mettre en œuvre une validation personnalisée des jetons pour les fournisseurs d’identité tiers ou une logique d’autorisation complexe, avec une mise en cache facultative des résultats. Nous allons maintenant étudier la limitation du débit, la mise en cache et les plans d’utilisation dans API Gateway.
Questions Fréquemment Posées
La leçon « Autorisation : IAM, autoriseurs Lambda et Cognito » est-elle gratuite ?
Oui — le texte complet de « Autorisation : IAM, autoriseurs Lambda et Cognito » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours AWS Solutions Architect, passe à CoddyKit PRO. Le cours AWS Solutions Architect comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Autorisation : IAM, autoriseurs Lambda et Cognito » ?
Sécurisez les points de terminaison d’API avec des signatures IAM SigV4, des autoriseurs Lambda personnalisés ou des autoriseurs de groupes d’utilisateurs Amazon Cognito. Tu pratiques AWS Solutions Architect avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer AWS Solutions Architect ?
Aucune expérience préalable n'est requise. AWS Solutions Architect sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.
Combien de temps prend la leçon « Autorisation : IAM, autoriseurs Lambda et Cognito » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon AWS Solutions Architect ?
Oui. Chaque leçon AWS Solutions Architect inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- API REST ou API HTTP ou API WebSocket
- Intégrations : Lambda, HTTP et simulées
- Autorisation : IAM, autoriseurs Lambda et Cognito
- Limitation, mise en cache et plans d’utilisation