Secure Read-Only AWS S3 Access with OAuth 2.0 Roles

The request came in: secure read-only access to AWS S3, but only through OAuth 2.0. No shared keys. No IAM user sprawl. One clean role, scoped tight, and bound to an identity provider.

OAuth 2.0 with AWS S3 roles is the modern answer. It lets you map external identities to AWS IAM roles without permanent credentials. You issue short-lived tokens after a validated OAuth flow. Those tokens assume a role with strict read-only permissions to an S3 bucket.

First, define an IAM role in AWS with a trust policy linked to your OAuth 2.0 IdP—Cognito, Okta, Auth0, or another OIDC-compatible service. In the policy document, outline precise S3 actions, usually "s3:GetObject" and "s3:ListBucket", on the target bucket or path. Avoid s3:*. Keep the scope minimal.

Next, configure the IdP to map authenticated users to the AWS role. In OIDC, this means setting the role ARN and the provider ARN in the IdP configuration. AWS STS then accepts the IdP's token and issues temporary AWS credentials for the role.

Your application uses the OAuth access token to fetch AWS credentials via AssumeRoleWithWebIdentity. Use those credentials in the AWS SDK to perform read-only S3 operations. The OAuth 2.0 layer manages identity and revocation. AWS enforces access with the IAM policy. Tokens expire quickly by design, closing the window for misuse.

Testing matters. Verify that unapproved operations—upload, delete, modify—return AccessDenied. Rotate credentials and confirm apps handle automatic renewal from the IdP without disruption.

This pattern removes static credentials from code and systems. It centralizes access control in the IdP and IAM. It scales from one bucket to thousands with consistent policy enforcement.

See how this OAuth 2.0 AWS S3 read-only role flow runs end-to-end. Try it on hoop.dev and watch it go live in minutes.