Autorisation : IAM, autoriseurs Lambda et Cognito

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.

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.

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.

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.

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.

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.

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é.

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.

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.

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.

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.

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.