Application identity and authorization

Exam tasks: 4.1 (Skills 4.1.1 identity for application users with Amazon Cognito, 4.1.3 troubleshooting Cognito), 4.2 (Skills 4.2.1 Amazon Verified Permissions, 4.2.2 ABAC and RBAC strategies)

The decision: does your application's user need to sign in (a user pool), call AWS directly with credentials (an identity pool), or be authorized against your own resources with fine-grained rules (Verified Permissions), and where is each check enforced?

The moving partsCopy Anchor Link

User pools vs identity poolsCopy Anchor Link

• Token types: the ID token carries user attributes (who the user is). The access token carries scopes and groups (what the app may call), and is the one to send to APIs. The refresh token gets new ones. You can revoke refresh tokens, and access tokens issued from them stop working at Cognito endpoints.
• Machine-to-machine: the client credentials grant with resource server scopes issues access tokens to services, no user involved.
• Feature plans: Lite, Essentials (the default for new pools) and Plus. Threat protection (compromised credential checks, adaptive authentication that scores risky sign-ins and can require MFA or block) is in Plus. Passkeys, email MFA and access token customization need Essentials or Plus.

Identity pools in detailCopy Anchor Link

• Each identity is authenticated or unauthenticated (guest), and each type maps to an IAM role. Keep the guest role tiny, for example PutObject to one upload prefix.
• Role selection: a default role, rules that map a token claim to a role, or the cognito:preferred_role claim from user pool groups.
• Attributes for access control: map token claims to principal tags, then write ABAC policies such as "only objects under users/${aws:PrincipalTag/sub}/".
• Role trust policies must trust cognito-identity.amazonaws.com and pin cognito-identity.amazonaws.com:aud to your identity pool ID and amr to authenticated or unauthenticated.
• The enhanced flow is the default. The basic (classic) flow lets the client call AssumeRoleWithWebIdentity itself and bypasses role rules, so leave it off unless you need it.

API Gateway authorizersCopy Anchor Link

• Mutual TLS on a custom domain authenticates clients by certificate, in addition to any authorizer.
• Cache Lambda authorizer results carefully: a cached allow for one path can be reused for others with the same token if the returned policy is too broad.

Amazon Verified PermissionsCopy Anchor Link

• A managed policy decision point for your own applications. Policies are written in Cedar and stored in a policy store with a schema of principals, actions and resources.
• Your app, or an API Gateway Lambda authorizer that Verified Permissions can generate, calls IsAuthorized, IsAuthorizedWithToken (passing a Cognito or OIDC token from an identity source) or BatchIsAuthorized.
• Default deny, and a forbid always beats a permit. The same shape as IAM, applied to your app's objects.
• Policy templates let you create per-resource grants ("share this document with Priya") without writing a new policy by hand.
• Every decision can be logged, which answers "who could see patient record 88?" for auditors.

permit (
  principal in Clinic::Role::"nurse",
  action in [Clinic::Action::"viewChart"],
  resource
)
when { resource.ward == principal.ward };

RBAC or ABACCopy Anchor Link

• Most real designs mix both: a role decides the kind of access, attributes decide which resources.
• ABAC depends on tag integrity. Control who can set tags (aws:RequestTag, aws:TagKeys, tag policies) or users can grant themselves access.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• Amazon Cognito user pools and identity pools
• Identity pools console overview
• What is Amazon Verified Permissions?
• Controlling access to REST APIs in API Gateway