Authentication
Multistore has two distinct authentication concerns:
- Client authentication — How clients prove their identity to the proxy
- Backend authentication — How the proxy authenticates with backend object stores
Client Authentication
Clients authenticate with the proxy using one of three methods:
| Method | Use Case | How It Works |
|---|---|---|
| Anonymous | Public datasets | No credentials needed for GET/HEAD/LIST |
| Long-lived access keys | Service accounts, internal tools | Static AccessKeyId/SecretAccessKey with SigV4 signing |
| OIDC/STS temporary credentials | CI/CD, user sessions, federated identity | Exchange a JWT from an OIDC provider for scoped temporary credentials |
The proxy verifies all signed requests using standard AWS Signature Version 4 (SigV4). Any S3-compatible client works without modification — just set the endpoint URL.
The OIDC/STS flow is the recommended approach for most use cases. See Client Auth Setup for configuration details.
Backend Authentication
The proxy authenticates with backend object stores using one of two methods:
| Method | Use Case | How It Works |
|---|---|---|
| Static credentials | Simple setups | access_key_id/secret_access_key stored in the proxy config |
| OIDC backend auth | Production, credential-free | Proxy acts as its own OIDC provider, exchanges self-signed JWTs for cloud credentials |
OIDC backend auth eliminates the need to store long-lived backend credentials. See Backend Auth for details.
Related Topics
- Sealed Session Tokens — How temporary credentials are encrypted for stateless runtimes