Hosting a static site? Having difficulties with authentication?

S3 Auth provides secure external access to your organization’s AWS S3 buckets. Never has it been easier to grant clients, stakeholders, and partners granular access to individual S3 buckets within your AWS account. Users sign up either through email or a SSO provider such as Google or Facebook. Account administrators then assign users to buckets and voilà – users through the S3 Auth portal can securely view a curated selection of S3 hosted websites, web applications, and files.

Security and ease of use are key; S3 Auth is backed by OAuth2 and OpenID Connect (OIDC) with a serverless architecture enabling industry-standard security and high scalability, all with minimal costs. Furthermore, our email-based user pools are PCI and HIPAA-compliant.

Rather than building authentication for each statically-hosted application, S3 Auth provides a single sign-on portal for your users to login through with minimal infrastructure and development. This is perfect for sharing application development with stakeholders, presenting confidential content to users, or providing member-only application access. With S3 Auth you can focus on content building and superb user experiences, rather than the complexity, overhead, and cost of user management and authentication for external user access.

https://s3auth.austincorso.com

Background

Authentication without a server can be difficult.

Statically hosted sites, such as those deployed to AWS S3, typically require a backend service to provide the authentication and authorization for access control. Credentials are passed at login from client to server in exchange for a session token. This token is re-validated on each subsequent request against a database or third-party login provider such as Google or Facebook. Protected resources are then restricted based on application-specific users, roles, and permissions.

Generally, only a backend service can securely communicate with an identity provider without exposing auth keys to the client. This typically involves looking up a session token against a session database or validating a JSON Web Token signature against public keys from a third-party identity provider.

Federated identity provider protocols such as OAuth and SAML provide frameworks that allow users to login with a third-party account and use that provider’s token to authorize users. OpenID Connect further standardizes this concept of identity across providers, establishing a common framework for the identification and authentication of users. Using these protocols, an application can leverage a third-party’s identity provider, but still requires a server to conceal the application’s auth keys. With S3 Auth this server requirement is lifted.

Note: OAuth 2.0’s implicit grant type attempts to circumvent this need for a client secret. Use of the implicit grant type is cautioned though as it eliminates authentication between the client application and the authorization server. This typically means shorter access token lifetimes and increased security risk, especially those involving XSS (Cross-Site Scripting) attacks.

Authentication and authorization code can be difficult to develop and requires dedicated infrastructure, diminishing some of the big advantages of the serverless nature of static-site hosting. Remove the complexity of authenticated static site hosting and save. Get in touch at https://s3auth.austincorso.com.