Security
Application Identity, Tokens, Roles, and Fine-Grained Authorization
CoreSeparate application-user identity, bearer-token validation, AWS workload credentials, role assumption, permissions, and cross-service authorization.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
Secure code places every identity decision at the right layer. A signed user token, an IAM role session, an execution role, and a resource permission are not interchangeable, even when one request crosses all of them.
Must Know
- Authentication establishes who the caller is; authorization decides whether that identity may perform the requested action on the requested resource.
- Amazon Cognito user pools provide application-user sign-up, sign-in, and tokens. Cognito identity pools can exchange supported identities for temporary AWS credentials associated with IAM roles.
- A bearer-token API must validate signature and trusted issuer, audience, expiration, and required claims or scopes before treating the request as authorized.
- AWS service calls normally use AWS credentials and Signature Version 4 through an SDK or signing implementation, not an application bearer token.
- Workloads on AWS should obtain temporary credentials from an execution, task, instance, or other workload role through the credential provider chain.
- STS AssumeRole returns temporary credentials when the caller is permitted to assume the role and the role trust policy accepts that principal.
- An identity policy defines what a principal session may do; a role trust policy defines who may assume the role. Cross-account or resource-policy paths can require authorization on both sides.
- Fine-grained application authorization must derive trusted user or tenant context from validated identity and enforce it on every action and data access.
Compare and Distinguish
- Amazon Cognito vs IAM/STS: Cognito serves application-user identity and federation; IAM and STS define AWS principals, permissions, role trust, and temporary AWS credentials.
- Authentication vs authorization: a valid identity or token does not automatically permit every application action.
- Bearer token vs signed AWS call: bearer tokens authorize supported application/API flows; AWS credentials sign AWS service API requests.
- Identity policy vs role trust policy: the permissions policy controls session actions; the trust policy controls which principal can create the session.
- User identity vs workload identity: preserve the user context needed for application authorization, but let each workload use its own scoped role for AWS service calls.
- Same-account vs cross-account access: cross-account paths often need a target-side trust or resource grant plus caller-side permission.
Scenario examples
- Scenario: A consumer app needs registration and JWTs for its API. Use a Cognito user pool and validate the token claims at the API boundary.
- Scenario: Signed-in users must upload only to an approved S3 prefix. Exchange the supported identity for scoped temporary role credentials rather than distributing access keys.
- Scenario: A Lambda function calls DynamoDB. Let the runtime supply execution-role credentials and scope that role to the required table operations.
- Scenario: A workload in account B must assume a role in account A. Configure caller permission and target trust, then use the returned temporary credentials.
Exam traps
- A valid token signature does not prove that issuer, audience, scope, expiry, or resource ownership is correct.
- An API key is not application-user authentication.
- A role trust policy does not grant the assumed role permission to use application resources.
- A caller-side Allow alone does not create every cross-account access path.
- Do not create IAM users and long-term keys for application users, containers, or functions when a federation or workload-role path exists.
- Hiding a UI control or filtering a response after a broad fetch is not fine-grained authorization.
Key takeaways
- Identify the principal and credential type at every hop.
- Validate bearer-token claims before applying application authorization.
- Use temporary workload credentials and least-privilege policies for AWS calls.
- Keep role trust, role permissions, resource policies, and application authorization distinct.
- Enforce tenant and resource ownership from trusted context on every operation.
How it works
- An application user signs in with the configured identity provider and receives tokens.
- The API validates token integrity and claims, then enforces action and resource rules.
- Each workload receives temporary AWS credentials from its role and signs downstream service requests.
- IAM evaluates applicable principal permissions, resource permissions, trust, conditions, and explicit denies.
When to use it
- Use Cognito user pools for application-user directory and token flows.
- Use supported federation or identity-pool flows when application users need scoped temporary AWS credentials.
- Use workload roles for Lambda, EC2, ECS, and other AWS-hosted code.
- Use STS AssumeRole for authorized temporary delegation, including cross-account operation.
- Use application authorization for ownership, tenant, and business-action decisions that IAM alone does not express.
Security and governance implications
- Never log complete bearer tokens, temporary credentials, access keys, or sensitive identity claims.
- Scope token audiences and permissions to the intended API and action.
- Prefer short-lived role credentials and narrow resource/action conditions.
- Derive tenant identity from validated claims rather than an untrusted request parameter.
Failure signals and diagnosis
- For a rejected token, inspect signature key, issuer, audience, expiry, scope, and clock handling.
- For AssumeRole denial, inspect caller permission, target trust, conditions, session context, and any explicit deny.
- For an AWS API denial, identify the actual runtime principal before editing a policy.
- For cross-tenant exposure, trace the trusted tenant claim through authorization, data keys, and cache keys.
More detail
- The target skill is implementing application and workload access, not administering IAM user and group lifecycles.
- Temporary credentials have an expiration and are obtained from the supported role or federation flow; do not persist them as application secrets.
- An authorizer can establish token validity and claims, while application code or a service authorization layer may still need resource-specific decisions.
- Cross-service authentication identifies the calling workload; authorization still scopes what that workload may do.
Ready for the quiz?
- What does a Cognito user pool provide that IAM does not provide to application users?
- Which token properties must an API validate beyond the signature?
- What two permission surfaces are involved in AssumeRole?
- Why should a user token not be passed as the credential for every AWS service call?
- Where should a tenant boundary be enforced?
Related objectives
- D2.1 — Implement authentication and/or authorization for applications and AWS services
- 2.1.1 — Use an identity provider to implement federated access (for example, Amazon Cognito, IAM)
- 2.1.2 — Secure applications by using bearer tokens
- 2.1.3 — Configure programmatic access to AWS
- 2.1.4 — Make authenticated calls to AWS services
- 2.1.5 — Assume an IAM role
- 2.1.6 — Define permissions for IAM principals
- 2.1.7 — Implement application-level authorization for fine-grained access control
- 2.1.8 — Handle cross-service authentication in microservice architectures