API authorization and tokens: DVA-C03 study notes and practice questions
What to know about API authorization and tokens for the DVA-C03 exam, from the Security domain (26% of the exam guide), then 3 free questions to test it. Part of the DVA-C03 study guide.
API questions describe a client, a protected endpoint and a requirement such as “only paying customers,” “only signed-in users” or “for one hour only.” Match the requirement to the control that proves identity or limits use.
Ways to authorize callers in API Gateway
IAM authorization signs each request with SigV4. Good for services and users already in AWS.
Cognito user pool authorizer checks the JWT that a user pool issued. Good for signed-in app users.
Lambda authorizer runs your code. A TOKEN authorizer reads one header, and a REQUEST authorizer reads several identity sources. It returns an allow or deny policy, and the result can be cached on the identity sources.
API keys with usage plans set request rate and quota for paying customers. An API key identifies a client for metering. It is not authentication on its own, so pair it with another control.
HTTP API JWT authorizer checks a token’s signature, issuer and audience (or client_id for access tokens without aud) with no code.
Resource policies allow or deny calls from named accounts, IP ranges (aws:SourceIp) or VPC endpoints (aws:SourceVpce). For a cross-account caller using IAM authorization, both the resource policy and the caller’s identity policy must allow execute-api:Invoke.
Status codes
A Lambda authorizer that throws an Unauthorized error, or a missing identity source, gives 401 Unauthorized. An authorizer that returns a Deny policy gives 403 Forbidden. SDKs that retry sign-in only on 401 will not retry on 403.
Authorizer caching reuses a decision: a TOKEN authorizer caches by the token, and a REQUEST authorizer by all its identity sources together. If a tenant value is not an identity source, a cached result can apply to the wrong caller. The cached policy is reused for every method the token calls, so a policy that names only the first method denies the rest; allow all the methods the token may call, for example with a wildcard.
Presigned URLs
A presigned URL puts a signature in the query string of an S3 request, so the holder can use one operation (such as GetObject or PutObject) without AWS credentials. The URL is signed with the credentials of the principal that created it, and it expires, at most 7 days later when signed with Signature Version 4. A URL signed with temporary role credentials stops working when those credentials expire, even if the URL’s own lifetime is longer.
CloudFront signed URLs and cookies
Use a signed URL for one file, and signed cookies when a viewer needs many files, such as a whole streaming path. Each carries a policy with an expiry time, and optionally an allowed IP range or path. CloudFront checks the signature against a public key that you register in a trusted key group. Never put the private key in the browser.
How to choose
Scenario wording
Answer
Only signed-in users may call the API
Cognito user pool authorizer or JWT check
Partner systems call an API with AWS credentials
IAM authorization
Custom token logic with tenant checks
Lambda authorizer, with the tenant in the cache key
Paying customers have a rate limit and quota
API key with a usage plan
One file, shared for an hour, no login
Presigned S3 URL
Viewers of a private video library, many files
CloudFront signed cookies
Log in and protect a single file download
Signed URL from CloudFront, not an open S3 bucket
Common traps
Using an API key as the only control on a sensitive API.
Expecting a 403 to make an SDK refresh a token. Only 401 triggers that retry.
Forgetting the identity source in an authorizer cache key.
A cached authorizer policy that allows only the first method called.
Assuming a presigned URL outlives the role session that signed it.
Giving the browser the CloudFront private key.
Choosing signed cookies for a single file when a signed URL is simpler.
A logistics company exposes a REST API in Amazon API Gateway to carriers.
Carriers send opaque access tokens from the company's own identity provider, which is not Amazon Cognito and does not issue JWTs. The only way to check a token is to call the provider's introspection endpoint, and a carrier typically reuses one token for many calls within minutes. The company wants to keep introspection calls low.
Which solution meets these requirements?
Choose one answer.
AA. Create a Cognito user pool authorizer, and import each carrier's opaque access token into the user pool for validation.
BB. Create a Lambda authorizer that calls the introspection endpoint, returns an IAM policy and caches the result.
CC. Move the API to an HTTP API and add a JWT authorizer that points at the identity provider's issuer URL and audience.
DD. Create a usage plan and require each carrier to send its access token as the x-api-key header on every request.
Show the answer and explanation
Answer: B
A. Wrong: A Cognito user pool authorizer validates tokens that the user pool itself issued. Opaque tokens from another provider cannot be imported and checked this way, so every call would be rejected. Learn more: Controlling access to REST APIs (opens in a new tab)
B. Right: Correct. A Lambda authorizer can run any custom check, such as an HTTP call to the provider, and returns an IAM policy that allows or denies the call. Caching the returned policy means repeated calls with the same token do not call the introspection endpoint again. Learn more: Lambda authorizers for REST APIs (opens in a new tab)
C. Wrong: A JWT authorizer validates signed JWTs against the issuer's keys. The carriers' tokens are opaque, so there is no signature or claim set for it to check.
D. Wrong: Usage plans and API keys meter and throttle callers that are already authorized. They are not an authentication mechanism, and API Gateway would never check the token against the provider. Learn more: Controlling access to REST APIs (opens in a new tab)
Explanation
Opaque tokens that can be checked only by calling a provider's introspection endpoint need custom logic, which a Lambda authorizer provides. It returns an IAM policy, and enabling authorization caching stops repeat calls with the same token from reaching the provider. Cognito and JWT authorizers need tokens they can validate themselves, and API keys are for metering, not authorization.
A payments service runs as Amazon ECS tasks that use an IAM role named payments-task.
It must call one method of an Amazon API Gateway REST API in the same account, and only tasks using that role may invoke the method. The team does not want to create or rotate any tokens, passwords or API keys.
Which TWO actions should the developer take? (Choose two.)
Choose two answers.
AA. Set the method's authorization type to AWS_IAM.
BB. Create an API key, attach it to a usage plan and place the key in the task definition's environment variables.
CC. Allow execute-api:Invoke on the method's ARN in the task role, and sign the service's requests with Signature Version 4.
DD. Create a Cognito user pool authorizer and send the task role's ARN in the Authorization header on each call.
EE. Add a VPC link to the method so that only traffic from the ECS service's subnets reaches the integration.
B. Wrong: API keys identify callers for throttling and quotas, not for authorization, and the key would be a secret that the team must create and rotate. This goes against the stated requirement. Learn more: Controlling access to REST APIs (opens in a new tab)
C. Right: Correct. The caller's role must be allowed to invoke the method, and each request must be signed with the role's temporary credentials. The AWS SDKs and signing libraries do this using the credentials that ECS provides to the task. Learn more: Controlling access with IAM permissions (opens in a new tab)
D. Wrong: A user pool authorizer expects a token issued by the user pool, and a role ARN is just text that anyone could copy. It would prove nothing about the caller.
E. Wrong: A VPC link lets API Gateway reach private backends; it does not control who can call the API. It does nothing to restrict callers to one role.
Explanation
IAM authorization needs two settings: the method must use the AWS_IAM authorization type, and the caller's role must be allowed execute-api:Invoke on the method and sign requests with Signature Version 4. No tokens or keys are created or rotated. API keys, user pool authorizers and VPC links do not identify an IAM role.
A company publishes a REST API in Amazon API Gateway for its partners' internal tools.
Only requests from the partners' two office ranges, 203.0.113.0/24 and 198.51.100.0/24, may reach the API. All other callers must be rejected by API Gateway before the Lambda backend runs. The backend code must not change, and the company does not want to add more AWS services.
What should the developer do?
Choose one answer.
AA. Add a Lambda authorizer that compares the X-Forwarded-For header with the two ranges and returns a Deny policy otherwise.
BB. Associate a security group that allows only the two ranges with the API's regional endpoint.
CC. Attach a resource policy to the API that denies execute-api:Invoke unless aws:SourceIp is within the two ranges.
DD. Issue an API key for each office, add each to a usage plan and require an API key on every method.
Show the answer and explanation
Answer: C
A. Wrong: This adds a Lambda function to build and run on each request, and the X-Forwarded-For header can be set by the caller, so it is not a trustworthy source address. A resource policy checks the real source address natively. Learn more: Lambda authorizers for REST APIs (opens in a new tab)
B. Wrong: Security groups attach to network interfaces such as EC2 instances and load balancers, not to API Gateway APIs. API Gateway offers resource policies for restricting source IP addresses.
An API Gateway resource policy can allow or deny invocation by source IP using the aws:SourceIp condition, and it is enforced by API Gateway before any backend runs. A Lambda authorizer would add code and rely on a spoofable header, security groups do not apply to API Gateway, and API keys are for usage tracking.
Want more on API authorization and tokens? The 5 full-length practice sets have 15 more API authorization and tokens questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →