Identities and resource authorization | AWS Developer Associate: applications and operations

Concept and mechanism

Lambda uses an execution role for permission to access AWS services. Define necessary actions and resources, avoiding permanent package credentials. This technical identity differs from the user calling the application. A Cognito JWT needs validation before trusting claims: signature, issuer, validity, expected use, and applicable client or audience. Base64 decoding merely makes content readable. Even a valid token does not establish access to every report. The application must connect identity, authorized context, and requested resource. A browser-supplied tenant is not authoritative unless checked against that identity.

Guided application

In a fictional funds portal, test that account A cannot list, open, or download B reports. Enforcement belongs on the server, including paths the interface does not expose. If an AWS call is denied, record the action, resource, and effective identity and investigate applicable policies. Adding another Allow does not override an explicit Deny. For temporary S3 object sharing, a presigned URL carries access capability while valid and authorized. Limit lifetime and operation, avoid logs containing the complete URL, and explain that possessing the link may permit access.

IN PRACTICE

An API with valid JWTs and cross-customer access needs object authorization. Shortening token lifetime may limit exposure time but does not fix the missing access rule.

Common pitfalls

Confusing authentication with authorization; trusting UUIDs as a barrier; broad permissions to hide AccessDenied; presigned URLs in shared tickets.

Related topics: Secrets, keys, and useful logs · Artifacts, tests, and environments

Take this idea with you

Validate the requester and decide which resource that identity may access.

Create account

Reference: Cognito JWT verification · DVA-C02; exam guide 2.1