Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Contrôler et gérer l'accès au protocole HTTP APIs dans API Gateway
API Gateway prend en charge plusieurs mécanismes pour contrôler et gérer l’accès à votre API :
+ Les **autorisateurs Lambda utilisent** les fonctions Lambda pour contrôler l'accès à. APIs Pour de plus amples informations, veuillez consulter [Contrôlez l'accès au HTTP APIs avec des AWS Lambda autorisateurs](http-api-lambda-authorizer.md).
+ **Les autorisateurs JWT utilisent des** jetons Web JSON pour contrôler l'accès à. APIs Pour de plus amples informations, veuillez consulter [Contrôlez l'accès au HTTP APIs avec les autorisateurs JWT dans API Gateway](http-api-jwt-authorizer.md).
+ Les **rôles et politiques AWS IAM standard** offrent des contrôles d'accès flexibles et robustes. Vous pouvez utiliser les rôles et les politiques IAM pour contrôler qui peut les créer et les gérer APIs, ainsi que les personnes habilitées à les invoquer. Pour de plus amples informations, veuillez consulter [Contrôlez l'accès au HTTP APIs avec l'autorisation IAM dans API Gateway](http-api-access-control-iam.md).
Pour renforcer votre posture de sécurité, nous vous recommandons de configurer un mécanisme d’autorisation pour toutes les routes de votre API HTTP. Vous devrez peut-être le faire pour vous conformer aux différents cadres de conformité. Pour plus d’informations, consultez [Amazon API Gateway controls](https://docs.aws.amazon.com/securityhub/latest/userguide/apigateway-controls.html) dans le *Guide de l’utilisateur AWS Security Hub *.
# Contrôlez l'accès au HTTP APIs avec des AWS Lambda autorisateurs
Vous utilisez un mécanisme d’autorisation Lambda pour contrôler l’accès à votre API HTTP à l’aide d’une fonction Lambda. Ensuite, lorsqu’un client appelle votre API, API Gateway appelle votre fonction Lambda. API Gateway utilise la réponse de votre fonction Lambda pour déterminer si le client peut accéder à votre API.
## Version du format de charge utile
La version du format de charge utile de l’autorisation spécifie le format des données qu’API Gateway envoie à un mécanisme d’autorisation Lambda, et la façon dont API Gateway interprète la réponse de Lambda. Si vous ne spécifiez pas de version de format de charge utile, la dernière version est AWS Management Console utilisée par défaut. Si vous créez un autorisateur Lambda à l'aide du AWS CLI, ou d'un SDK CloudFormation, vous devez spécifier un. `authorizerPayloadFormatVersion` Les valeurs prises en charge sont `1.0` et `2.0`.
Si vous avez besoin de compatibilité avec REST APIs, utilisez la version`1.0`.
Les exemples suivants montrent la structure de chaque version de format de charge utile.
------
#### [ 2.0 ]
```
{
"version": "2.0",
"type": "REQUEST",
"routeArn": "arn:aws:execute-api:us-east-1:123456789012:abcdef123/test/GET/request",
"identitySource": ["user1", "123"],
"routeKey": "$default",
"rawPath": "/my/path",
"rawQueryString": "parameter1=value1¶meter1=value2¶meter2=value",
"cookies": ["cookie1", "cookie2"],
"headers": {
"header1": "value1",
"header2": "value2"
},
"queryStringParameters": {
"parameter1": "value1,value2",
"parameter2": "value"
},
"requestContext": {
"accountId": "123456789012",
"apiId": "api-id",
"authentication": {
"clientCert": {
"clientCertPem": "CERT_CONTENT",
"subjectDN": "www.example.com",
"issuerDN": "Example issuer",
"serialNumber": "1",
"validity": {
"notBefore": "May 28 12:30:02 2019 GMT",
"notAfter": "Aug 5 09:36:04 2021 GMT"
}
}
},
"domainName": "id.execute-api.us-east-1.amazonaws.com",
"domainPrefix": "id",
"http": {
"method": "POST",
"path": "/my/path",
"protocol": "HTTP/1.1",
"sourceIp": "IP",
"userAgent": "agent"
},
"requestId": "id",
"routeKey": "$default",
"stage": "$default",
"time": "12/Mar/2020:19:03:58 +0000",
"timeEpoch": 1583348638390
},
"pathParameters": { "parameter1": "value1" },
"stageVariables": { "stageVariable1": "value1", "stageVariable2": "value2" }
}
```
------
#### [ 1.0 ]
```
{
"version": "1.0",
"type": "REQUEST",
"methodArn": "arn:aws:execute-api:us-east-1:123456789012:abcdef123/test/GET/request",
"identitySource": "user1,123",
"authorizationToken": "user1,123",
"resource": "/request",
"path": "/request",
"httpMethod": "GET",
"headers": {
"X-AMZ-Date": "20170718T062915Z",
"Accept": "*/*",
"HeaderAuth1": "headerValue1",
"CloudFront-Viewer-Country": "US",
"CloudFront-Forwarded-Proto": "https",
"CloudFront-Is-Tablet-Viewer": "false",
"CloudFront-Is-Mobile-Viewer": "false",
"User-Agent": "..."
},
"queryStringParameters": {
"QueryString1": "queryValue1"
},
"pathParameters": {},
"stageVariables": {
"StageVar1": "stageValue1"
},
"requestContext": {
"path": "/request",
"accountId": "123456789012",
"resourceId": "05c7jb",
"stage": "test",
"requestId": "...",
"identity": {
"apiKey": "...",
"sourceIp": "...",
"clientCert": {
"clientCertPem": "CERT_CONTENT",
"subjectDN": "www.example.com",
"issuerDN": "Example issuer",
"serialNumber": "a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1",
"validity": {
"notBefore": "May 28 12:30:02 2019 GMT",
"notAfter": "Aug 5 09:36:04 2021 GMT"
}
}
},
"resourcePath": "/request",
"httpMethod": "GET",
"apiId": "abcdef123"
}
}
```
------
## Format de réponse du mécanisme d’autorisation Lambda
La version du format de charge utile détermine également la structure de la réponse que vous devez renvoyer à partir de votre fonction Lambda.
### Réponse de la fonction Lambda pour le format 1.0
Si vous choisissez la version de format `1.0`, les mécanismes d’autorisation Lambda doivent renvoyer une politique IAM qui autorise ou refuse l’accès à votre route d’API. Vous pouvez utiliser la syntaxe de politique standard IAM dans la politique. Pour obtenir des exemples de politiques IAM, consultez [Contrôler l’accès pour l’appel d’une API](api-gateway-control-access-using-iam-policies-to-invoke-api.md). Vous pouvez transmettre des propriétés de contexte aux intégrations Lambda ou accéder aux journaux avec `$context.authorizer.property`. L’objet `context` est facultatif et `claims` est un espace réservé qui ne peut être utilisé comme objet contextuel. Pour en savoir plus, consultez la section [Personnalisation des journaux d’accès pour les API HTTP](http-api-logging-variables.md).
**Example**
****
```
{
"principalId": "abcdef",
"policyDocument": {
"Version":"2012-10-17",
"Statement": [
{
"Action": "execute-api:Invoke",
"Effect": "Allow|Deny",
"Resource": "arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]"
}
]
},
"context": {
"exampleKey": "exampleValue"
}
}
```
### Réponse de la fonction Lambda pour le format 2.0
Si vous choisissez la version de format `2.0`, vous pouvez renvoyer une valeur booléenne ou une politique IAM qui utilise la syntaxe de politique IAM standard de votre fonction Lambda. Pour renvoyer une valeur booléenne, activez des réponses simples pour le mécanisme d’autorisation. Les exemples suivants montrent le format que vous devez coder pour retourner votre fonction Lambda. L’objet `context` est facultatif. Vous pouvez transmettre des propriétés de contexte aux intégrations Lambda ou accéder aux journaux avec `$context.authorizer.property`. Pour en savoir plus, consultez la section [Personnalisation des journaux d’accès pour les API HTTP](http-api-logging-variables.md).
------
#### [ Simple response ]
```
{
"isAuthorized": true/false,
"context": {
"exampleKey": "exampleValue"
}
}
```
------
#### [ IAM policy ]
****
```
{
"principalId": "abcdef",
"policyDocument": {
"Version":"2012-10-17",
"Statement": [
{
"Action": "execute-api:Invoke",
"Effect": "Allow|Deny",
"Resource": "arn:aws:execute-api:{regionId}:{accountId}:{apiId}/{stage}/{httpVerb}/[{resource}/[{child-resources}]]"
}
]
},
"context": {
"exampleKey": "exampleValue"
}
}
```
------
## Exemple de fonctions d’autorisation Lambda
Les exemples de fonction Lambda Node.js suivants illustrent les formats de réponse requis que vous devez renvoyer à partir de votre fonction Lambda pour la version du format de charge utile `2.0`.
------
#### [ Simple response - Node.js ]
```
export const handler = async(event) => {
let response = {
"isAuthorized": false,
"context": {
"stringKey": "value",
"numberKey": 1,
"booleanKey": true,
"arrayKey": ["value1", "value2"],
"mapKey": {"value1": "value2"}
}
};
if (event.headers.authorization === "secretToken") {
console.log("allowed");
response = {
"isAuthorized": true,
"context": {
"stringKey": "value",
"numberKey": 1,
"booleanKey": true,
"arrayKey": ["value1", "value2"],
"mapKey": {"value1": "value2"}
}
};
}
return response;
};
```
------
#### [ Simple response - Python ]
```
import json
def lambda_handler(event, context):
response = {
"isAuthorized": False,
"context": {
"stringKey": "value",
"numberKey": 1,
"booleanKey": True,
"arrayKey": ["value1", "value2"],
"mapKey": {"value1": "value2"}
}
}
try:
if (event["headers"]["authorization"] == "secretToken"):
response = {
"isAuthorized": True,
"context": {
"stringKey": "value",
"numberKey": 1,
"booleanKey": True,
"arrayKey": ["value1", "value2"],
"mapKey": {"value1": "value2"}
}
}
print('allowed')
return response
else:
print('denied')
return response
except BaseException:
print('denied')
return response
```
------
#### [ IAM policy - Node.js ]
```
export const handler = async(event) => {
if (event.headers.authorization == "secretToken") {
console.log("allowed");
return {
"principalId": "abcdef", // The principal user identification associated with the token sent by the client.
"policyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Action": "execute-api:Invoke",
"Effect": "Allow",
"Resource": event.routeArn
}]
},
"context": {
"stringKey": "value",
"numberKey": 1,
"booleanKey": true,
"arrayKey": ["value1", "value2"],
"mapKey": { "value1": "value2" }
}
};
}
else {
console.log("denied");
return {
"principalId": "abcdef", // The principal user identification associated with the token sent by the client.
"policyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Action": "execute-api:Invoke",
"Effect": "Deny",
"Resource": event.routeArn
}]
},
"context": {
"stringKey": "value",
"numberKey": 1,
"booleanKey": true,
"arrayKey": ["value1", "value2"],
"mapKey": { "value1": "value2" }
}
};
}
};
```
------
#### [ IAM policy - Python ]
```
import json
def lambda_handler(event, context):
response = {
# The principal user identification associated with the token sent by
# the client.
"principalId": "abcdef",
"policyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Action": "execute-api:Invoke",
"Effect": "Deny",
"Resource": event["routeArn"]
}]
},
"context": {
"stringKey": "value",
"numberKey": 1,
"booleanKey": True,
"arrayKey": ["value1", "value2"],
"mapKey": {"value1": "value2"}
}
}
try:
if (event["headers"]["authorization"] == "secretToken"):
response = {
# The principal user identification associated with the token
# sent by the client.
"principalId": "abcdef",
"policyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Action": "execute-api:Invoke",
"Effect": "Allow",
"Resource": event["routeArn"]
}]
},
"context": {
"stringKey": "value",
"numberKey": 1,
"booleanKey": True,
"arrayKey": ["value1", "value2"],
"mapKey": {"value1": "value2"}
}
}
print('allowed')
return response
else:
print('denied')
return response
except BaseException:
print('denied')
return response
```
------
## Sources d’identité
Si vous le souhaitez, vous pouvez spécifier des sources d’identité pour un mécanisme d’autorisation Lambda. Les sources d’identité spécifient l’emplacement des données requises pour autoriser une demande. Par exemple, vous pouvez spécifier des valeurs d’en-tête ou de chaîne de requête en tant que sources d’identité. Si vous spécifiez des sources d’identité, les clients doivent les inclure dans la demande. Si la demande du client n’inclut pas les sources d’identité, API Gateway n’appelle pas votre mécanisme d’autorisation Lambda et le client reçoit une erreur `401`.
Le tableau suivant décrit les sources d’identité prises en charge pour un mécanisme d’autorisation Lambda.
| **Type** | **Exemple** | **Remarques** |
| --- | --- | --- |
| Valeur d'en-tête | \$1request.header. name | Les noms d'en-tête ne sont pas sensibles à la casse. |
| Valeur de chaîne de requête | \$1request.querystring. name | Les noms de chaîne de requête sont sensibles à la casse. |
| Variable de contexte | \$1contexte. variableName | Valeur d'une [variable de contexte](http-api-logging-variables.md) prise en charge. |
| Variable d'étape | \$1StageVariables. variableName | Valeur d'une [variable d'étape](http-api-stages.stage-variables.md). |
Vous pouvez également renvoyer directement ` {"errorMessage" : "Unauthorized"}` de votre fonction Lambda pour renvoyer une erreur `401` à vos clients. Si vous renvoyez directement une erreur `401` de votre fonction Lambda à vos clients, ne spécifiez aucune source d’identité lorsque vous créez votre mécanisme d’autorisation Lambda.
## Mise en cache des réponses du mécanisme d’autorisation
Vous pouvez activer la mise en cache pour un autorisateur Lambda en spécifiant un. [authorizerResultTtlInSeconds](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-authorizers.html#apis-apiid-authorizers-prop-createauthorizerinput-authorizerresultttlinseconds) Lorsque la mise en cache est activée pour un mécanisme d’autorisation, API Gateway utilise les sources d’identité de ce mécanisme comme clé de cache. Si un client spécifie les mêmes paramètres dans les sources d’identité au sein de la TTL configurée, API Gateway utilise le résultat du mécanisme d’autorisation mis en cache, plutôt que d’appeler votre fonction Lambda.
Pour activer la mise en cache, votre mécanisme d’autorisation doit avoir au moins une source d’identité.
Si vous activez des réponses simples pour un mécanisme d’autorisation, la réponse de ce mécanisme autorise ou refuse totalement toutes les demandes d’API qui correspondent aux valeurs de source d’identité mises en cache. Pour obtenir des autorisations plus détaillées, désactivez les réponses simples et renvoyez une politique IAM. En fonction de votre mécanisme d’autorisation, votre politique IAM peut avoir besoin de contrôler l’accès à plusieurs éléments.
Par défaut, API Gateway utilise la réponse du mécanisme d’autorisation mise en cache pour toutes les routes d’une API utilisant le mécanisme d’autorisation. Pour mettre en cache les réponses par route, ajoutez `$context.routeKey` aux sources d’identité de votre mécanisme d’autorisation.
## Création d’un mécanisme d’autorisation Lambda
Lorsque vous créez un mécanisme d’autorisation Lambda, vous spécifiez la fonction Lambda qu’API Gateway doit utiliser. Vous devez accorder l’autorisation à API Gateway d’appeler la fonction Lambda à l’aide de la politique de ressources de la fonction ou d’un rôle IAM. La commande [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-authorizer.html) suivante crée un mécanisme d’autorisation Lambda :
```
aws apigatewayv2 create-authorizer \
--api-id abcdef123 \
--authorizer-type REQUEST \
--identity-source '$request.header.Authorization' \
--name lambda-authorizer \
--authorizer-uri 'arn:aws:apigateway:us-west-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-west-2:123456789012:function:my-function/invocations' \
--authorizer-payload-format-version '2.0' \
--enable-simple-responses
```
La commande [add-permission](https://docs.aws.amazon.com/cli/latest/reference/lambda/add-permission.html) suivante met à jour la stratégie de ressources de la fonction Lambda afin qu’elle autorise API Gateway à invoquer la fonction. Si API Gateway n’a pas l’autorisation d’appeler votre fonction, les clients reçoivent un `500 Internal Server Error`.
```
aws lambda add-permission \
--function-name my-authorizer-function \
--statement-id apigateway-invoke-permissions-abc123 \
--action lambda:InvokeFunction \
--principal apigateway.amazonaws.com \
--source-arn "arn:aws:execute-api:us-west-2:123456789012:api-id/authorizers/authorizer-id"
```
Une fois que vous avez créé un mécanisme d’autorisation et que vous avez accordé à API Gateway l’autorisation de l’appeler, mettez à jour votre route de manière à l’utiliser. La commande [update-route](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-route.html) suivante ajoute le mécanisme d’autorisation Lambda à la route. Si votre mécanisme d’autorisation Lambda utilise la mise en cache des stratégies, veillez à mettre à jour la politique afin qu’elle contrôle l’accès à la route supplémentaire.
```
aws apigatewayv2 update-route \
--api-id abcdef123 \
--route-id abc123 \
--authorization-type CUSTOM \
--authorizer-id def123
```
## Dépannage des autorisations Lambda
Si API Gateway ne peut pas appeler votre autorisation Lambda, ou si votre mécanisme d’autorisation Lambda renvoie une réponse dans un format non valide, les clients reçoivent un `500 Internal Server Error`.
Pour résoudre les erreurs, [activez la journalisation des accès](http-api-logging.md) pour votre étape d’API. Incluez la variable de journalisation `$context.authorizer.error` dans votre format de journal.
Si les journaux indiquent qu’API Gateway n’a pas l’autorisation d’appeler votre fonction, mettez à jour la politique de ressources de votre fonction ou fournissez un rôle IAM pour accorder à API Gateway l’autorisation d’appeler votre mécanisme d’autorisation.
Si les journaux indiquent que votre fonction Lambda renvoie une réponse non valide, vérifiez qu’elle renvoie une réponse dans le [format requis](#http-api-lambda-authorizer.payload-format-response).
# Contrôlez l'accès au HTTP APIs avec les autorisateurs JWT dans API Gateway
Vous pouvez utiliser des jetons Web JSON (JWTs) dans le cadre des frameworks [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html) et [OAuth 2.0](https://oauth.net/2/) pour restreindre l'accès des clients à votre. APIs
Si vous configurez un autorisateur JWT pour un itinéraire de votre API, API Gateway valide les demandes d'API soumises par JWTs les clients. API Gateway autorise ou refuse les demandes basées sur la validation de jeton, et éventuellement, les étendues dans le jeton. Si vous configurez des étendues pour un routage, le jeton doit inclure au moins une des étendues du routage.
Vous pouvez configurer des autorisations distinctes pour chaque route d’une API ou utiliser le même mécanisme d’autorisation pour plusieurs routes.
**Note**
Il n'existe aucun mécanisme standard permettant de différencier les jetons d'accès JWT des autres types de jetons JWTs, tels que les jetons OpenID Connect ID. À moins que vous n’ayez besoin de jetons d’ID pour l’autorisation de l’API, nous vous recommandons de configurer vos routes pour qu’elles requièrent des étendues d’autorisation. Vous pouvez également configurer vos mécanismes d’autorisation JWT pour exiger des émetteurs ou des audiences que votre fournisseur d’identité utilise uniquement lors de l’émission de jetons d’accès JWT.
## Autorisation des demandes d’API avec un mécanisme d’autorisation JWT
API Gateway utilise le workflow général suivant pour autoriser les demandes de routes configurées pour utiliser un mécanisme d’autorisation JWT.
1. Vérifiez [https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-authorizers-authorizerid.html#apis-apiid-authorizers-authorizerid-prop-authorizer-identitysource](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-authorizers-authorizerid.html#apis-apiid-authorizers-authorizerid-prop-authorizer-identitysource) pour un jeton. `identitySource` peut inclure uniquement le jeton, ou le jeton préfixé avec `Bearer`.
1. Décodez le jeton.
1. Vérifiez l’algorithme et la signature du jeton en utilisant la clé publique récupérée auprès du `jwks_uri` de l’émetteur. Actuellement, seuls les algorithmes basés sur RSA sont pris en charge. API Gateway peut mettre en cache la clé publique pendant deux heures. Lorsque vous effectuez la rotation des clés, une bonne pratique consiste à prévoir un délai de grâce pendant lequel les anciennes et les nouvelles clés sont valides.
1. Validez les demandes. API Gateway évalue les demandes de jeton suivantes :
+ [https://datatracker.ietf.org/doc/html/rfc7517#section-4.5](https://datatracker.ietf.org/doc/html/rfc7517#section-4.5) : le jeton doit avoir une demande d’en-tête qui correspond à la clé du `jwks_uri` ayant signé le jeton.
+ [https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1) : doit correspondre à l’[https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-authorizers-authorizerid.html#apis-apiid-authorizers-authorizerid-model-jwtconfiguration](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-authorizers-authorizerid.html#apis-apiid-authorizers-authorizerid-model-jwtconfiguration) configuré pour le mécanisme d’autorisation.
+ [https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) ou `client_id` : doit correspondre à l’une des entrées [https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-authorizers-authorizerid.html#apis-apiid-authorizers-authorizerid-model-jwtconfiguration](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-authorizers-authorizerid.html#apis-apiid-authorizers-authorizerid-model-jwtconfiguration) configurées pour le mécanisme d’autorisation. API Gateway ne valide `client_id` que si `aud` n’est pas présent. Si `aud` et `client_id` sont présents, API Gateway évalue `aud`.
+ [https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) – doit être postérieure à l’heure actuelle (UTC).
+ [https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5) – doit être antérieure à l'heure actuelle(UTC).
+ [https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.6](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.6) – doit être antérieure à l'heure actuelle(UTC).
+ [https://datatracker.ietf.org/doc/html/rfc6749#section-3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) ou `scp` : le jeton doit inclure au moins une des portées dans les [https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-routes-routeid.html#apis-apiid-routes-routeid-prop-updaterouteinput-authorizationscopes](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-routes-routeid.html#apis-apiid-routes-routeid-prop-updaterouteinput-authorizationscopes) de la route.
Si l’une de ces étapes échoue, API Gateway refuse la demande d’API.
Après avoir validé le JWT, API Gateway transmet les revendications du jeton à l’intégration de la route d’API. Les ressources backend, telles que les fonctions Lambda, peuvent accéder aux revendications JWT. Par exemple, si le JWT inclut une revendication d’identité `emailID`, elle est disponible pour une intégration Lambda dans `$event.requestContext.authorizer.jwt.claims.emailID`. Pour plus d’informations sur la charge utile qu’API Gateway envoie aux intégrations Lambda, consultez [Création d'intégrations de AWS Lambda proxy pour HTTP APIs dans API Gateway](http-api-develop-integrations-lambda.md).
## Créer un mécanisme d’autorisation JWT
Avant de créer un mécanisme d’autorisation JWT, vous devez enregistrer une application cliente auprès d’un fournisseur d’identité. Vous devez également avoir créé une API HTTP. Pour obtenir des exemples de création d'une API HTTP, veuillez consulter [Création d’une API HTTP](http-api-develop.md#http-api-examples).
### Création d’un mécanisme d’autorisation JWT à l’aide de la console
La procédure suivante montre comment créer un mécanisme d’autorisation JWT à l’aide de la console.
**Pour créer un mécanisme d’autorisation JWT à l’aide de la console**
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Choisissez une API HTTP.
1. Dans le panneau de navigation principal, choisissez **Autorisation**.
1. Choisissez l’onglet **Gérer les mécanismes d’autorisation**.
1. Choisissez **Créer**.
1. Pour **Type du mécanisme d’autorisation**, choisissez **JWT**.
1. Configurez votre mécanisme d’autorisation JWT et spécifiez une **source d’identité** qui définit la source du jeton.
1. Choisissez **Créer**.
#### Créez un autorisateur JWT à l'aide du AWS CLI
La commande [create-authorizer](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-authorizer.html) suivante crée un mécanisme d’autorisation JWT. Pour `jwt-configuration`, spécifiez les paramètres `Audience` et `Issuer` pour votre fournisseur d’identité. Si vous utilisez Amazon Cognito comme fournisseur d’identité, `IssuerUrl` est `https://cognito-idp.us-east-2.amazonaws.com/userPoolID`.
```
aws apigatewayv2 create-authorizer \
--name authorizer-name \
--api-id api-id \
--authorizer-type JWT \
--identity-source '$request.header.Authorization' \
--jwt-configuration Audience=audience,Issuer=IssuerUrl
```
##### Créez un autorisateur JWT en utilisant AWS CloudFormation
Le CloudFormation modèle suivant crée une API HTTP avec un autorisateur JWT qui utilise Amazon Cognito comme fournisseur d'identité.
La sortie du CloudFormation modèle est une URL pour une interface utilisateur hébergée par Amazon Cognito où les clients peuvent s'inscrire et se connecter pour recevoir un JWT. Une fois qu’un client s’est connecté, il est redirigé vers votre API HTTP avec un jeton d’accès dans l’URL. Pour invoquer l’API avec le jeton d’accès, remplacez le symbole `#` de l’URL par un `?` pour utiliser le jeton comme paramètre de chaîne de requête.
##### Exemple de CloudFormation modèle
```
AWSTemplateFormatVersion: '2010-09-09'
Description: |
Example HTTP API with a JWT authorizer. This template includes an Amazon Cognito user pool as the issuer for the JWT authorizer
and an Amazon Cognito app client as the audience for the authorizer. The outputs include a URL for an Amazon Cognito hosted UI where clients can
sign up and sign in to receive a JWT. After a client signs in, the client is redirected to your HTTP API with an access token
in the URL. To invoke the API with the access token, change the '#' in the URL to a '?' to use the token as a query string parameter.
Resources:
MyAPI:
Type: AWS::ApiGatewayV2::Api
Properties:
Description: Example HTTP API
Name: api-with-auth
ProtocolType: HTTP
Target: !GetAtt MyLambdaFunction.Arn
DefaultRouteOverrides:
Type: AWS::ApiGatewayV2::ApiGatewayManagedOverrides
Properties:
ApiId: !Ref MyAPI
Route:
AuthorizationType: JWT
AuthorizerId: !Ref JWTAuthorizer
JWTAuthorizer:
Type: AWS::ApiGatewayV2::Authorizer
Properties:
ApiId: !Ref MyAPI
AuthorizerType: JWT
IdentitySource:
- '$request.querystring.access_token'
JwtConfiguration:
Audience:
- !Ref AppClient
Issuer: !Sub https://cognito-idp.${AWS::Region}.amazonaws.com/${UserPool}
Name: test-jwt-authorizer
MyLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Runtime: nodejs18.x
Role: !GetAtt FunctionExecutionRole.Arn
Handler: index.handler
Code:
ZipFile: |
exports.handler = async (event) => {
const response = {
statusCode: 200,
body: JSON.stringify('Hello from the ' + event.routeKey + ' route!'),
};
return response;
};
APIInvokeLambdaPermission:
Type: AWS::Lambda::Permission
Properties:
FunctionName: !Ref MyLambdaFunction
Action: lambda:InvokeFunction
Principal: apigateway.amazonaws.com
SourceArn: !Sub arn:${AWS::Partition}:execute-api:${AWS::Region}:${AWS::AccountId}:${MyAPI}/$default/$default
FunctionExecutionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Service:
- lambda.amazonaws.com
Action:
- 'sts:AssumeRole'
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
UserPool:
Type: AWS::Cognito::UserPool
Properties:
UserPoolName: http-api-user-pool
AutoVerifiedAttributes:
- email
Schema:
- Name: name
AttributeDataType: String
Mutable: true
Required: true
- Name: email
AttributeDataType: String
Mutable: false
Required: true
AppClient:
Type: AWS::Cognito::UserPoolClient
Properties:
AllowedOAuthFlows:
- implicit
AllowedOAuthScopes:
- aws.cognito.signin.user.admin
- email
- openid
- profile
AllowedOAuthFlowsUserPoolClient: true
ClientName: api-app-client
CallbackURLs:
- !Sub https://${MyAPI}.execute-api.${AWS::Region}.amazonaws.com
ExplicitAuthFlows:
- ALLOW_USER_PASSWORD_AUTH
- ALLOW_REFRESH_TOKEN_AUTH
UserPoolId: !Ref UserPool
SupportedIdentityProviders:
- COGNITO
HostedUI:
Type: AWS::Cognito::UserPoolDomain
Properties:
Domain: !Join
- '-'
- - !Ref MyAPI
- !Ref AppClient
UserPoolId: !Ref UserPool
Outputs:
SignupURL:
Value: !Sub https://${HostedUI}.auth.${AWS::Region}.amazoncognito.com/login?client_id=${AppClient}&response_type=token&scope=email+profile&redirect_uri=https://${MyAPI}.execute-api.${AWS::Region}.amazonaws.com
```
## Mise à jour d’une route pour utiliser un mécanisme d’autorisation JWT
Vous pouvez utiliser la console AWS CLI, le ou un AWS SDK pour mettre à jour un itinéraire afin d'utiliser un autorisateur JWT.
### Mise à jour d’une route pour utiliser un mécanisme d’autorisation JWT à l’aide de la console
La procédure suivante montre comment mettre à jour un mécanisme d’autorisation JWT à l’aide de la console.
**Pour créer un mécanisme d’autorisation JWT à l’aide de la console**
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Choisissez une API HTTP.
1. Dans le panneau de navigation principal, choisissez **Autorisation**.
1. Choisissez une méthode, puis sélectionnez votre mécanisme d’autorisation dans le menu déroulant, puis choisissez **Attacher le mécanisme d’autorisation**.
#### Mettez à jour un itinéraire pour utiliser un autorisateur JWT à l'aide du AWS CLI
La commande [update-route](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-route.html) suivante met à jour une route de manière à ce qu’elle utilise un mécanisme d’autorisation JWT :
```
aws apigatewayv2 update-route \
--api-id api-id \
--route-id route-id \
--authorization-type JWT \
--authorizer-id authorizer-id \
--authorization-scopes user.email
```
# Contrôlez l'accès au HTTP APIs avec l'autorisation IAM dans API Gateway
Vous pouvez activer l’autorisation IAM pour les routes des API HTTP. Lorsque l'autorisation IAM est activée, les clients doivent utiliser [Signature Version 4 (SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) pour signer leurs demandes avec AWS des informations d'identification. API Gateway n’appelle votre route API que si le client dispose de l’autorisation `execute-api` pour la route.
L'autorisation IAM pour HTTP APIs est similaire à celle pour [REST APIs](api-gateway-control-access-using-iam-policies-to-invoke-api.md).
**Note**
Les politiques relatives aux ressources ne sont actuellement pas prises en charge pour le protocole HTTP APIs.
Pour des exemples de politiques IAM qui accordent aux clients l'autorisation d'invoquer APIs, consultez[Contrôler l’accès pour l’appel d’une API](api-gateway-control-access-using-iam-policies-to-invoke-api.md).
## Activation d’une autorisation IAM pour une route
La commande [update-route](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-route.html) suivante active l’autorisation IAM pour une route d’API HTTP :
```
aws apigatewayv2 update-route \
--api-id abc123 \
--route-id abcdef \
--authorization-type AWS_IAM
```