Authentication vs. Authorization Roles

Two Roles, Two Audiences

When you create an Identity Pool, you configure exactly two IAM roles. Every credential request gets assigned to one of them — no exceptions. Understanding which role a user lands in, and why, is the core of Identity Pool design.

1. Authenticated Role

• Who gets it? Any user who presents a valid, verified token from a trusted identity provider.
• Permissions: Scoped to what a logged-in user of your application should be able to do.
• Example Policy: Allow uploading files to their own private folder in S3, reading their own record in DynamoDB, or invoking a specific Lambda function.

2. Unauthenticated (Guest) Role

• Who gets it? Users who have not logged in, provided you explicitly enable "Allow unauthenticated identities" in the Identity Pool settings. This is off by default — you must consciously opt in.
• Permissions: Minimal, read-only access to public resources only.
• Example Policy: Allow reading from a public announcements DynamoDB table or downloading assets from a public S3 prefix.
• Use Case: A gaming app that lets you play the tutorial level before asking you to create an account. The guest session gets a real Identity ID and real (but limited) credentials, so progress can be saved temporarily and later merged when the user signs up.

The critical design principle: the Guest Role should be treated as untrusted by default. Grant only what is absolutely necessary for the unauthenticated experience. Any sensitive data access must require the Authenticated Role.