Secrets & managed identity
A common weakness in web applications is a long-lived password or API key sitting in a config file or environment variable, waiting to be leaked. Oblifee is built to avoid that class of problem: there is no standing database password anywhere, and other secrets are fetched from a secure vault at the moment they are needed rather than kept lying around.
No database password to steal
When Oblifee needs to talk to its database, it does not present a stored password. Instead it asks the cloud platform for a short-lived token tied to the application's own managed identity - an identity the platform issues and rotates automatically, that never exists as a secret you could copy. The token is valid for a short window and is refreshed as needed.
Because the credential is minted on demand and expires quickly:
- There is no password in a config file, an environment variable, or the source code to leak.
- A token that did somehow escape would be useless within minutes.
- Rotation is automatic - there is nothing for an administrator to remember to change.
The same identity is what the database checks when it grants access, and it is deliberately given only the permissions Oblifee needs (read-write on your workspace data, subject to row-level security; read-only on the regulatory brain).
Other secrets: pulled from a vault at runtime
Some things genuinely are secrets - the credentials for outbound services, signing keys, and the like. Oblifee keeps these in a managed secret vault and retrieves them at runtime, again using its managed identity to authenticate to the vault. They are not baked into the application image and not written into its configuration.
| Approach | What it protects against |
|---|---|
| Managed-identity tokens for the database | A stolen or leaked standing database password |
| Secrets fetched from a vault at runtime | Secrets sitting in config, images or source control |
| Least-privilege identity | An over-powered credential being abused if compromised |
:::info Configuration vs. secrets Ordinary configuration - which region to run in, which features are on - is not sensitive and is set through the environment. Secrets never travel that way. They are requested from the vault when required and are not exposed to the browser or to logs. :::
Why this matters for a buyer
- Reduced blast radius. The most valuable credential - database access - simply does not exist as a stealable secret.
- No manual key rotation. Automatic, short-lived tokens remove a whole category of operational mistakes.
- Auditable access. Access to the vault and the database is tied to a managed identity the platform tracks, not to a shared password passed around a team.
Where to go next
- Tenant isolation - what that database identity is, and is not, allowed to see.
- Authentication - the same managed-identity principle applied to how users sign in.
- Application hardening - defence in the browser, on top of these server-side guarantees.