The threat model: a Tauri app runs a Rust backend and a webview frontend. If credentials touch the webview, they're accessible to JavaScript — same exposure as a browser extension. That's not acceptable for long-lived R2 keys with read/write/delete access to production storage.
Here's what I ended up with:
*Vault layer* Argon2id KDF derives a 256-bit key from the user's passphrase. The vault state is checked at the start of every Tauri command handler. If the vault is locked, the command returns an error before any R2 operation executes. The frontend never holds the key — it only knows whether the vault is open or closed.
*Credential storage* R2 access keys are stored in the OS keychain via the keyring crate (Windows Credential Manager, macOS Keychain, libsecret on Linux). Nothing sensitive touches the filesystem or app settings.
*Backend-only R2 requests* All S3 operations run in Rust using the AWS SDK. The frontend calls Tauri commands like `list_objects` or `upload_file` — it never constructs signed requests or holds credentials long enough to use them. The signing happens entirely in the backend.
*Session lock* On macOS: NSWorkspaceSessionDidResignActiveNotification triggers vault auto-lock when the session goes inactive. On Windows: WM_WTSSESSION_CHANGE handles the same. On Linux: XScreenSaver / logind signals.
The cross-platform session lock was the most painful part — each OS has a completely different event model and Tauri doesn't abstract this for you.
*The tradeoff* This architecture means the frontend is essentially a dumb UI. Any operation that needs R2 access goes through a Tauri command. That's more round-trips than a purely frontend approach but the security boundary is clean and auditable.
Happy to discuss the implementation details — particularly the Argon2id parameterisation choices and the keyring abstraction across the three platforms.