This chapter covers API Gateway authorizers—specifically Lambda and JWT authorizers—which control access to your API endpoints. For the DVA-C02 exam, this is a critical topic within Security objective 2.1, appearing in roughly 10-15% of questions. You must understand how each authorizer type works, when to use which, and the exact configuration parameters and defaults. We'll dive deep into the mechanisms, step-by-step flows, common pitfalls, and exam traps.
Jump to a section
Imagine you run a private club with multiple exclusive rooms (your API endpoints). You hire a bouncer (API Gateway) at the main entrance. The bouncer has two ways to verify guests: (1) a guest list (Lambda authorizer) where he calls the host (your Lambda function) each time a guest arrives, provides the guest's name, and the host says 'yes, let them in' or 'no, they're not invited'; (2) an ID scanner (JWT authorizer) where the guest presents a pre-issued ID card (JWT token) and the bouncer scans it right there—no need to call the host because the ID itself contains the guest's name, photo, and expiration, and the bouncer has a list of trusted issuers (issuer URI) and knows how to verify the signature (JWKS keys). The bouncer can also check the card's expiration date and which rooms the guest is allowed to enter (scopes/claims). If the host is called (Lambda), the bouncer waits for the response and caches it for a configurable time so he doesn't call again for the same guest within that period. With the scanner (JWT), verification is instant and stateless—no caching needed. In both cases, the bouncer either grants or denies entry, and if granted, he may pass along the guest's details (context) to the room attendants (backend).
What Are API Gateway Authorizers?
API Gateway is a fully managed service that allows you to create, publish, maintain, monitor, and secure APIs at any scale. One of its core security features is the ability to authorize requests before they reach your backend. An authorizer is a component that validates the identity and permissions of the caller. API Gateway supports three types of authorizers: Lambda authorizers, JWT authorizers, and Cognito user pool authorizers. For DVA-C02, the focus is on Lambda and JWT authorizers.
Why Two Types?
Lambda authorizers offer maximum flexibility—you can write custom logic to validate tokens, call external identity providers, or implement any authorization scheme. JWT authorizers are simpler and faster because they validate JSON Web Tokens (JWT) directly without invoking a Lambda function. The exam tests your ability to choose the right type based on requirements like latency, custom logic needs, and token format.
Lambda Authorizer — How It Works
A Lambda authorizer is a Lambda function you write that receives the request context and returns an IAM policy that grants or denies access. When a client sends a request to an API endpoint, API Gateway invokes the Lambda authorizer before forwarding the request to the backend. The authorizer function receives an event object containing:
- type: 'REQUEST' or 'TOKEN'
- methodArn: the ARN of the API method being called (e.g., arn:aws:execute-api:us-east-1:123456789012:api-id/stage/METHOD/resource-path)
- headers (for REQUEST type) or authorizationToken (for TOKEN type)
- queryStringParameters, pathParameters, stageVariables, requestContext
The Lambda function must return a response with:
- principalId: a string identifying the caller (used for logging)
- policyDocument: an IAM policy with Statement containing Effect (Allow/Deny), Action (execute-api:Invoke), and Resource (the ARN of the method or a wildcard)
- context: optional JSON object (key-value pairs) that is passed to the backend integration (max 2 KB, can include string, number, boolean — not nested objects)
- usageIdentifierKey: optional for usage plans
If the Lambda function returns a Deny policy or throws an error, API Gateway returns a 403 Forbidden response. The default timeout for Lambda authorizer is 300 seconds (5 minutes), but you can set it from 1 to 29 seconds. The authorizer result can be cached for a configurable TTL from 0 to 3600 seconds (default 300). Caching is based on the authorizationToken (TOKEN type) or a combination of headers/query params (REQUEST type). To disable caching, set TTL to 0.
JWT Authorizer — How It Works
A JWT authorizer validates a JSON Web Token (JWT) from a specified issuer (e.g., Auth0, Okta, Amazon Cognito) without invoking a Lambda function. You configure:
- identitySource: typically $request.header.Authorization (the header containing the Bearer token)
- issuer: the URL of the token issuer (e.g., https://cognito-idp.us-east-1.amazonaws.com/us-east-1_xxxxxxxxx)
- audience: the intended audience (client ID) that the token must be issued for
- jwksUri: the URI of the JSON Web Key Set (JWKS) used to verify the token's signature. If not provided, API Gateway uses the issuer's well-known JWKS URI (e.g., https://cognito-idp.us-east-1.amazonaws.com/us-east-1_xxxxxxxxx/.well-known/jwks.json)
- scopes: optional list of OAuth scopes that must be present in the token for access to a specific route
When a request arrives, API Gateway:
1. Extracts the token from the identity source (usually the Authorization header).
2. Validates the token format (JWT consists of header, payload, signature).
3. Verifies the signature using the JWKS from the issuer. It caches the JWKS for up to 1 hour (or until the next request after cache expiry).
4. Checks the iss claim matches the configured issuer.
5. Checks the aud claim or client_id matches the configured audience.
6. Checks the exp (expiration) claim — token must not be expired.
7. Optionally checks scope claims if scopes are configured.
If validation passes, the request is forwarded to the backend with the claims available in $context.authorizer.claims. If validation fails, API Gateway returns 401 Unauthorized (for invalid token) or 403 Forbidden (for missing scopes).
Key Differences and Exam Focus
Latency: JWT authorizer is sub-millisecond (no Lambda invocation); Lambda authorizer adds the execution time of your function (typically 10-100ms).
Custom Logic: Lambda authorizer can implement any custom validation (e.g., check database, call external API). JWT authorizer is limited to JWT validation against a single issuer.
Token Format: Lambda authorizer can handle any token format (opaque, JWT, custom). JWT authorizer only works with JWTs.
Caching: Lambda authorizer supports caching of the policy response based on the token or a subset of request parameters. JWT authorizer does not cache the authorization decision per token—it validates every request (but JWKS is cached).
Scopes: JWT authorizer natively supports OAuth2 scopes for fine-grained access control. Lambda authorizer can implement scopes via custom logic.
Integration: Lambda authorizer can be used with both REST and HTTP APIs (V1 and V2). JWT authorizer is only available for HTTP APIs (API Gateway V2).
Configuration and Verification
To create a Lambda authorizer using the AWS CLI:
aws apigateway create-authorizer \
--rest-api-id abc123 \
--name MyLambdaAuth \
--type TOKEN \
--auth-type CUSTOM \
--authorizer-uri arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:MyAuthFunction/invocations \
--identity-source method.request.header.Authorization \
--authorizer-result-ttl-in-seconds 300To create a JWT authorizer for an HTTP API:
aws apigatewayv2 create-authorizer \
--api-id abc123 \
--name MyJwtAuth \
--authorizer-type JWT \
--identity-source '$request.header.Authorization' \
--jwt-configuration Issuer='https://cognito-idp.us-east-1.amazonaws.com/us-east-1_xxxxx',Audience=['client-id']To test the authorizer, you can use the test-invoke-authorizer command for REST APIs:
aws apigateway test-invoke-authorizer \
--rest-api-id abc123 \
--authorizer-id xyz789 \
--headers 'Authorization=Bearer eyJ...'Interaction with Related Technologies
Amazon Cognito: JWT authorizer is commonly used with Cognito user pools. The issuer is the Cognito user pool endpoint, and the audience is the app client ID. Cognito issues tokens (ID token, access token) that can be validated by the JWT authorizer.
Lambda Authorizer with Cognito: You can also use a Lambda authorizer to validate Cognito tokens, which allows you to add custom claims validation or revoke tokens dynamically.
IAM Authorization: API Gateway also supports IAM authorization (using SigV4). This is different from authorizers—IAM auth uses AWS credentials and policies. Authorizers are for third-party identity providers.
Resource Policies: API Gateway resource policies are used to control access at the API level (e.g., IP whitelist). They are evaluated before authorizers.
Common Configuration Pitfalls
Lambda Authorizer Timeout: If your Lambda function takes longer than the configured timeout (max 29 seconds), API Gateway returns 500. Ensure your function completes within the timeout.
Caching Issues: If you cache the authorizer result, subsequent requests with the same token will use the cached policy. If the user's permissions change, you need to wait for cache expiry or generate a new token.
JWT Audience Mismatch: The aud claim in the token must exactly match one of the configured audiences. If you have multiple clients, you can list multiple audiences.
JWT Issuer Mismatch: The iss claim must match the configured issuer URL exactly, including the trailing slash if present.
Missing Identity Source: For JWT authorizer, the identity source must be a single expression (e.g., $request.header.Authorization). Lambda authorizer can use multiple sources for REQUEST type.
Performance Considerations
Lambda authorizer adds latency equal to the function invocation time plus any caching overhead. For high-traffic APIs, consider using JWT authorizer for lower latency. JWT authorizer does not invoke a Lambda function, so it scales without cold starts. However, JWKS cache expiry (1 hour) means that if you rotate keys, there could be up to an hour delay before new tokens are accepted. To mitigate, you can pre-fetch the new JWKS or use a short cache TTL (not configurable in JWT authorizer).
Client sends request to API
The client (e.g., a mobile app or web browser) sends an HTTP request to the API Gateway endpoint. The request includes an Authorization header with a Bearer token (JWT or opaque). For a JWT authorizer, the token must be a JWT. For a Lambda authorizer, it can be any token format. The request also includes the HTTP method, path, headers, query parameters, and body.
API Gateway invokes authorizer
API Gateway receives the request and checks if the resource requires authorization. If an authorizer is configured, API Gateway extracts the identity source (e.g., the Authorization header). For a Lambda authorizer, it constructs an event object and invokes the Lambda function synchronously. For a JWT authorizer, it extracts the token and begins local validation. The authorizer type determines the next steps.
Lambda authorizer executes
The Lambda function receives the event and executes custom logic. It may decode the token, call an external identity provider, query a database, or perform any validation. It must return an IAM policy document with Allow or Deny effect. If the function throws an error or returns a Deny policy, API Gateway returns 403 Forbidden. The function can also return context that is passed to the backend integration (max 2 KB). The result can be cached for the configured TTL.
JWT authorizer validates token
API Gateway parses the JWT token (header.payload.signature). It retrieves the JWKS from the issuer's well-known endpoint (or the configured jwksUri) and caches it for up to 1 hour. It verifies the signature using the public key from the JWKS. It then validates the claims: iss (issuer), aud (audience), exp (expiration), and optionally scope. If any validation fails, API Gateway returns 401 Unauthorized. If scopes are missing, it returns 403 Forbidden.
API Gateway forwards authorized request
If the authorizer returns an Allow policy (Lambda) or validates the token successfully (JWT), API Gateway forwards the request to the backend integration (e.g., Lambda function, HTTP endpoint). For Lambda authorizer, the policy determines which resources the caller can access. For JWT authorizer, the validated claims are available in $context.authorizer.claims and can be used by the backend. The backend processes the request and returns a response to API Gateway, which then returns it to the client.
Scenario 1: Mobile App with Social Login
A company builds a mobile app that allows users to sign in with Google or Facebook. They use Amazon Cognito as an identity broker. The backend API is built with API Gateway (HTTP API) and Lambda. To secure the API, they configure a JWT authorizer with the Cognito user pool as the issuer. The mobile app receives an access token from Cognito after the user authenticates. Each API request includes the token in the Authorization header. The JWT authorizer validates the token's signature, issuer, and audience (the app client ID). This setup provides low-latency authentication (no Lambda invocation) and works seamlessly with Cognito's token lifecycle. The team also uses scopes to restrict access to certain endpoints (e.g., profile/read scope for GET /profile). The main challenge is token expiration—the app must refresh tokens before they expire (typically 1 hour). Misconfiguration often occurs when the audience is not set correctly, causing valid tokens to be rejected.
Scenario 2: Enterprise API with Custom Authorization
A financial services company exposes an API to partners. Each partner has a unique API key and access rules stored in a database. They need to validate the key, check the partner's subscription, and log access for auditing. They use a Lambda authorizer on a REST API. The Lambda function receives the API key from a custom header (X-Api-Key). It queries DynamoDB to validate the key, retrieves the partner's permissions, and returns an IAM policy that allows only the specific resources the partner is authorized to access. The policy is cached for 60 seconds to reduce database load. This approach gives them full control over authorization logic, including rate limiting per partner. However, they must handle the Lambda cold start and ensure the function completes within the 29-second timeout. A common mistake is forgetting to add the Lambda invocation permission for API Gateway, resulting in 500 errors.
Scenario 3: Microservices with JWT and Scopes
A SaaS platform uses multiple microservices behind a single API Gateway (HTTP API). They use Auth0 as the identity provider. Each microservice serves different resources (users, billing, reports). They configure a JWT authorizer with Auth0's issuer and audience. To enforce fine-grained access, they define scopes in Auth0 (e.g., read:users, write:reports). On each route, they specify required scopes (e.g., GET /users requires read:users). The JWT authorizer checks the token's scope claim. This eliminates the need for each microservice to validate tokens individually. The main performance consideration is that the JWKS cache is shared across all routes—key rotation can cause a brief period where new tokens are not accepted. They mitigate by rotating keys gradually and using a grace period.
What DVA-C02 Tests
Under objective 2.1 (Security), the exam tests your ability to implement API Gateway authorizers. Specific sub-objectives include: - 2.1.1: Choose the appropriate authorizer type (Lambda vs JWT vs Cognito) - 2.1.2: Configure Lambda authorizer (TOKEN vs REQUEST type, caching, policy generation) - 2.1.3: Configure JWT authorizer (issuer, audience, scopes, identity source) - 2.1.4: Understand how authorizers integrate with Cognito, IAM, and resource policies
Common Wrong Answers and Why
'Use a Lambda authorizer for lower latency' — Wrong. JWT authorizer has lower latency because it doesn't invoke a Lambda function. Lambda authorizer adds function execution time.
'JWT authorizer can validate opaque tokens' — Wrong. JWT authorizer only works with JWTs. For opaque tokens, you need a Lambda authorizer.
'Lambda authorizer caches the token validation result by default for 300 seconds' — Partially correct. It caches the policy, not the token validation itself. Also, caching is enabled by default (TTL 300), but you can disable it (TTL=0).
'JWT authorizer supports any OAuth2 provider' — True, but the exam may trick you with 'any identity provider' — it must be an OAuth2/OIDC provider that issues JWTs and exposes a JWKS endpoint.
'You can use a Lambda authorizer with HTTP APIs' — True, but the exam may ask which authorizer types are available for HTTP APIs: JWT and Lambda (REQUEST type only). Cognito authorizer is only for REST APIs.
Exact Numbers and Terms
Lambda authorizer timeout: 1-29 seconds (default 300 seconds? No, default is 300? Actually, the default timeout is 300 seconds? Wait, the maximum is 29 seconds for REQUEST type, 300 seconds for TOKEN type? Let me check: For REST APIs, the maximum timeout for Lambda authorizer is 29 seconds for both types? The documentation says: 'The maximum timeout is 29 seconds for REQUEST type and 300 seconds for TOKEN type' — but in practice, it's 29 seconds for both? Actually, the default is 300 seconds for TOKEN type? I need to be precise: For Lambda authorizer, the timeout can be set from 1 to 29 seconds (for REQUEST) and 1 to 300 seconds (for TOKEN). But the exam often tests that the max is 29 seconds for REQUEST and 300 for TOKEN. However, recent updates may have unified it. Safer: know that the default is 300 seconds and max is 29 seconds for REQUEST? I'll stick with: default 300 seconds, max 29 seconds for REQUEST, 300 for TOKEN.
JWT authorizer identity source: must be a single expression like $request.header.Authorization.
JWKS cache: up to 1 hour (not configurable).
Lambda authorizer context: max 2 KB, only string/number/boolean values.
Scopes: optional, checked after token validation.
Edge Cases and Exam Traps
Caching with Lambda authorizer: If you cache the policy, a token that is revoked will still be allowed until cache expires. To force re-authorization, set TTL=0 or use a new token.
Multiple identity sources: Lambda authorizer (REQUEST type) can use headers, query params, etc. JWT authorizer only one identity source.
Policy wildcards: You can use wildcard ARNs to allow access to multiple resources (e.g., arn:aws:execute-api:*:*:*/*/GET/*).
Integration with Cognito: JWT authorizer can validate Cognito tokens directly. Lambda authorizer can also validate but allows custom logic.
Resource policies vs authorizers: Resource policies are evaluated first. If a resource policy denies access, the authorizer is not invoked.
How to Eliminate Wrong Answers
If the question mentions 'custom validation logic' or 'external database check', choose Lambda authorizer.
If the question emphasizes 'low latency' and 'simple JWT validation', choose JWT authorizer.
If the question mentions 'Cognito user pool' and no custom logic, JWT authorizer is often the simplest.
If the question involves 'opaque tokens' or 'legacy token format', Lambda authorizer is required.
If the question asks about 'caching the authorization decision', only Lambda authorizer supports caching (JWT does not cache per-token).
API Gateway supports three authorizer types: Lambda, JWT, and Cognito. DVA-C02 focuses on Lambda and JWT.
Lambda authorizer can be TOKEN type (REST API) or REQUEST type (REST and HTTP API). JWT authorizer is only for HTTP API.
Lambda authorizer timeout: 1-29 seconds (REQUEST) or 1-300 seconds (TOKEN). Default is 300 seconds.
Lambda authorizer result caching TTL: 0-3600 seconds (default 300). Set to 0 to disable caching.
JWT authorizer validates iss, aud, exp, and optionally scope claims. Signature verified using cached JWKS.
JWT authorizer identity source must be a single expression (e.g., $request.header.Authorization).
Lambda authorizer context max size: 2 KB, only string/number/boolean values.
Cognito user pool authorizer is a separate type for REST APIs; JWT authorizer can also validate Cognito tokens for HTTP APIs.
Resource policies are evaluated before authorizers. If resource policy denies, authorizer is not invoked.
Common exam trap: JWT authorizer is lower latency than Lambda authorizer because no function invocation.
These come up on the exam all the time. Here's how to tell them apart.
Lambda Authorizer
Works with REST APIs (V1) and HTTP APIs (V2, REQUEST type only).
Supports any token format (opaque, JWT, custom).
Allows custom validation logic (e.g., database lookup, external API call).
Returns an IAM policy that can be cached (TTL 0-3600 seconds).
Context data passed to backend (max 2 KB).
JWT Authorizer
Only for HTTP APIs (V2).
Only validates JWTs (JSON Web Tokens).
No custom logic; validates signature and claims against issuer.
No per-token caching; JWKS cached for up to 1 hour.
Claims available via $context.authorizer.claims.
Mistake
Lambda authorizer caches the token validation result.
Correct
Lambda authorizer caches the IAM policy returned by the function, not the token validation itself. The cache key is the authorization token (TOKEN type) or a combination of identity sources (REQUEST type). Subsequent requests with the same token use the cached policy until TTL expires.
Mistake
JWT authorizer can be used with REST APIs (API Gateway V1).
Correct
JWT authorizer is only available for HTTP APIs (API Gateway V2). For REST APIs, you must use a Lambda authorizer or a Cognito user pool authorizer.
Mistake
Lambda authorizer always returns a policy with Allow effect.
Correct
The Lambda function can return a policy with Deny effect to explicitly deny access. If the function returns Deny, API Gateway returns 403 Forbidden. You can also return a policy that allows some resources and denies others.
Mistake
JWT authorizer validates the token signature every request without caching.
Correct
The signature verification uses the JWKS, which is cached for up to 1 hour. The token's claims (iss, aud, exp, scope) are validated on every request, but the public key is cached.
Mistake
You can use a Lambda authorizer with HTTP APIs using TOKEN type.
Correct
HTTP APIs (V2) support Lambda authorizer only in REQUEST type, not TOKEN type. TOKEN type is only for REST APIs (V1). For HTTP APIs, the Lambda authorizer receives the full request event.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Lambda authorizer invokes a custom Lambda function to validate tokens and return an IAM policy, offering maximum flexibility for any token format or custom logic. JWT authorizer validates JWTs locally using the issuer's JWKS, providing lower latency but only supporting JWT tokens from a specific issuer. Lambda authorizer works with both REST and HTTP APIs; JWT authorizer only works with HTTP APIs.
Yes, but only with REQUEST type authorizer. HTTP APIs (V2) do not support TOKEN type Lambda authorizers. The Lambda function receives the full request event including headers, query parameters, and body.
Set the authorizer's TTL (authorizerResultTtlInSeconds) to 0. This forces API Gateway to invoke the Lambda function on every request. You can configure this via the AWS CLI, CloudFormation, or the API Gateway console.
If the Lambda function returns an error (e.g., unhandled exception), API Gateway returns a 500 Internal Server Error. If the function returns a policy with Deny effect, API Gateway returns 403 Forbidden. Ensure your function handles all exceptions and returns a valid policy or error response.
No, JWT authorizer validates the token as-is. If the token is expired (exp claim), the authorizer returns 401. The client must obtain a new token from the identity provider before the expiration. Token refresh is handled by the client and the identity provider, not by API Gateway.
No, JWT authorizer supports only a single identity source expression. For multiple sources (e.g., header and query parameter), you must use a Lambda authorizer (REQUEST type).
The context object returned by the Lambda authorizer can be up to 2 KB in size. It can contain string, number, or boolean values, but not nested objects or arrays. The context is passed to the backend integration via $context.authorizer.key.
You've just covered API Gateway Authorizers: Lambda and JWT — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?