AWS S3 Read-Only Access with JWT-Based Authentication

The bucket held secrets no one should change, only read. That was the rule. And the lock was not a password, but a signed token that expired before it could be stolen.

AWS S3 read-only roles with JWT-based authentication give you precision access and airtight security without managing static credentials. You grant a role that can only perform GetObject and list operations, then you tie that role to a trust policy that accepts temporary credentials exchanged via a verified JSON Web Token. This turns your S3 bucket into a controlled resource—open to the right users, closed to everyone else.

First, define the least-privilege IAM policy. It should allow s3:GetObject and optional s3:ListBucket only for the targeted bucket and its objects. No PutObject, no DeleteObject. The access boundary lives in IAM, not in code.

Next, create an IAM role with a trust policy that uses an identity provider. This can be Amazon Cognito, AWS IAM Identity Center, or an external IdP that supports OIDC. The trust policy must match the JWT issuer, audience, and subject claims. AWS will only issue temporary credentials if the token is valid and signed.

When a user logs in, the system verifies their credentials with your IdP. A valid JWT reaches AWS Security Token Service through AssumeRoleWithWebIdentity. The service inspects the token, applies the trust policy, and if it passes, returns temporary access keys with read-only rights to your S3 bucket. These keys expire quickly, closing the door to lingering attacks.

The result is an S3 bucket that serves files securely to users authenticated in real time, without leaks from hardcoded tokens or long-term credentials. Scaling is simple: any service or user that can present a proper JWT gains the read-only access you define. Everyone else hits a wall.

This approach works across browser apps, backend APIs, and CLI tools. It enforces compliance with minimal configuration, cutting unnecessary permissions. You can rotate keys without downtime because STS does it for you every time the JWT changes.

If you want to set this up without drowning in IAM JSON, see it in action at hoop.dev. You can get a live, JWT-based read-only S3 role running in minutes—no scaffolding, no boilerplate, just secure access done right.