Share Your AWS re:Post Experience - Quick 3 Question Survey
Help us improve AWS re:Post! We're interested in understanding how you use re:Post and its impact on your AWS journey. Please take a moment to complete our brief 3-question survey.
¿Cómo soluciono los errores 403 prohibidos de HTTP al utilizar un autorizador Lambda con una API de REST de API Gateway?
Las llamadas a mi API de REST de Amazon API Gateway reciben errores 403 prohibidos después de crear un autorizador de AWS Lambda. ¿Cómo soluciono estos errores?
Descripción breve
Este error puede producirse si:
- La función de autorización de Lambda devuelve un documento de política de AWS Identity and Access Management (IAM) que niega explícitamente el acceso a la persona que llama.
- La API tiene una política de recursos adjunta que niega explícitamente el acceso a la persona que llama.
Si la llamada a su API contiene un token o fuentes de identidad que faltan, son nulas o no están validadas, aparece un error 401 no autorizado. Para obtener más información, consulte ¿Por qué me aparecen errores 401 no autorizados de API Gateway después de crear un autorizador Lambda?
Nota: Este artículo aborda los errores 403 relacionados con los autorizadores de Lambda que están configurados únicamente para una API de REST. Para obtener información sobre cómo solucionar otros tipos de errores 403, consulte ¿Cómo soluciono los errores prohibidos 403 de HTTP desde API Gateway?
Resolución
Confirme la causa del error
Nota:
- Si aún no lo ha hecho, active CloudWatch Logs para su API de REST de API Gateway.
- Si recibe errores al ejecutar los comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), asegúrese de utilizar la versión más reciente de AWS CLI.
- Si ha realizado algún cambio en la configuración del autorizador, debe volver a implementar la API.
1. Revise el mensaje de error de la respuesta de API Gateway. Busque un mensaje de error similar a uno de los siguientes.
Ejemplo de mensaje de error para las funciones de autorización de Lambda que devuelven un documento de política de IAM con una denegación explícita
{ "message": "User is not authorized to access this resource with an explicit deny" }
Ejemplo de mensaje de error para las funciones de autorización de Lambda que devuelven un documento de política de IAM con una denegación implícita
{ "message": "User is not authorized to access this resource" }
Ejemplo de mensaje de error para las API REST que tienen una política de recursos adjunta que niega implícitamente el acceso a la persona que llama
{ "message": "User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn>" }
Ejemplo de mensaje de error para las API REST que tienen una política de recursos adjunta que niega explícitamente el acceso a la persona que llama
{ "message": "User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn> with an explicit deny" }
Nota: Para obtener más información sobre el comportamiento resultante cuando el acceso a una API de API Gateway está controlado por una política de IAM, consulte las tablas de resultados de la evaluación de políticas.
2. Consulte los registros de ejecución de API Gateway en CloudWatch para revisar el flujo de trabajo de autorización. Tenga en cuenta el resultado del autorizador de Lambda y el resultado de la evaluación de la política de recursos de API Gateway. Aparece un mensaje de error de registro similar a uno de los siguientes.
Ejemplo de mensaje de error de registro para cuando falta un token requerido o no coincide con la validación del token
Extended Request Id: MY92nHDwwwIdGxzR= Unauthorized request: <request-id>
Nota: El ID de solicitud extendida se genera aleatoriamente. El valor del ID de solicitud extendida en sus registros es diferente.
Ejemplo de mensaje de error de registro para cuando un autorizador de Lambda devuelve una política que deniega el acceso
Sending request to https://lambda.<region>.amazonaws.com/2015-03-31/functions/<lambda-authorizer-arn>/invocations Authorizer result body before parsing: { "principalId": "user", "policyDocument": { "Version": "2012-10-17", "Statement": [ { "Action": "execute-api:Invoke", "Effect": "Deny", "Resource": "<resource-arn>" } ] } } Using valid authorizer policy for principal: <principal> Successfully completed authorizer execution The client is not authorized to perform this operation.
**Nota:**La política devuelta depende de su autorizador de Lambda. Si el resource-arn de la política devuelta no incluye el recurso solicitante, la solicitud se denegará implícitamente.
Ejemplo de mensaje de error de registro para cuando la política de recursos de API Gateway deniega la solicitud
Extended Request Id: MY-BIVb4GEdGeZB= ExplicitDenyException User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn> with an explicit deny: <request-id>
Resuelva los errores de «no está autorizado a acceder a este recurso» del autorizador Lambda
Es posible que reciba los errores de no autorizado para acceder a este recurso de forma intermitente debido al almacenamiento en caché de políticas. Para confirmar que el almacenamiento en caché de autorización está activado, revise la configuración de su autorizador de Lambda en la consola de API Gateway. A continuación, realice una de las siguientes acciones:
- Para realizar una prueba única, ejecute el comando flush-stage-authorizers-cachede AWS CLI. Una vez vaciadas las entradas de la caché del autorizador, vuelve a llamar a la API.
- Desactive el almacenamiento en caché de políticas y, a continuación, vuelva a llamar a la API.
**Nota:**Cuando desactiva el almacenamiento en caché de políticas para un autorizador basado en parámetros de solicitud, API Gateway no valida las llamadas a su API antes de invocar la función de autorizador de Lambda. - Cambie la clave de caché del autorizador actualizando el nombre del encabezado especificado en Token Source (para autorizadores basados en token) o Identity Sources (para autorizadores basados en parámetros de solicitud). Reimplemente su API para confirmar los cambios. A continuación, llamar a su API otra vez usando el encabezado del token o las fuentes de identidad recién configuradas.
Si encuentra los errores de forma sistemática, determine por qué el autorizador deniega explícitamente el acceso a la persona que llama revisando el código de la función de autorización de Lambda. Si ha determinado que el problema se debe al almacenamiento en caché, puede actualizar el código para que permita el acceso a la persona que llama. Para obtener instrucciones, consulte ¿Por qué mi recurso proxy de API Gateway con un autorizador Lambda que tiene activado el almacenamiento en caché devuelve errores HTTP 403?
Resuelva los errores «no autorizado para realizar:execute-api:Invoke»
Determine la política de recursos de su API para determinar si la política de recursos de su API no es válida o si niega explícitamente el acceso a sus llamadas. Puede ver los registros de ejecución de su API para obtener el resultado de la respuesta de la política de recursos.
Para obtener más información, consulte la descripción general del lenguaje de la política de acceso de Amazon API Gateway y la política de autorizadores y recursos de Lambda.
Información relacionada
Utilice los autorizadores Lambda de API Gateway
Actualizaciones de una API REST que requieren reimplementarse
Controlar y administrar el acceso a una API REST en API Gateway
Vídeos relacionados


Contenido relevante
- Como solucionar el error: Supplied Policy document is breaching Cloudwatch Logs policy length limit.Respuesta aceptadapreguntada hace un meslg...
- preguntada hace 2 meseslg...
- preguntada hace 9 díaslg...
- preguntada hace un meslg...
- preguntada hace un díalg...
- OFICIAL DE AWSActualizada hace 3 meses
- OFICIAL DE AWSActualizada hace un año
- OFICIAL DE AWSActualizada hace 2 años
- OFICIAL DE AWSActualizada hace 3 meses