mirror of
https://github.com/agentrhq/authsome.git
synced 2026-09-19 01:34:19 +08:00
Manoj Bajaj
28 lines
1.5 KiB
Plaintext
28 lines
1.5 KiB
Plaintext
---
|
|
title: "Credential storage"
|
|
description: "How Authsome securely stores and encrypts credentials."
|
|
---
|
|
|
|
Authsome stores all credentials in a central encrypted key-value store, abstracting away the persistence layer from the authentication flows. The orchestrator determines what to read and write.
|
|
|
|
## Concept and motivation
|
|
|
|
Credentials like OAuth access tokens, refresh tokens, and API keys are sensitive. They need protection on disk, but the Authsome daemon still needs seamless access to them for token injection and refresh.
|
|
|
|
Instead of scattering credentials across config files or plain-text environment variables, Authsome puts them in a single Vault. A single Principal (a human or a team) owns each Vault.
|
|
|
|
## Encryption at rest
|
|
|
|
Authsome encrypts sensitive fields at rest so unauthorized file access doesn't expose your secrets.
|
|
|
|
- **AES-256-GCM**: Sensitive fields (`access_token`, `refresh_token`, `api_key`, `client_secret`) stay encrypted on disk.
|
|
- Non-sensitive routing data (`client_id`, connection names) stays in plaintext for fast lookups.
|
|
|
|
The Vault keeps credentials encrypted. The daemon decrypts them in-memory only when an active, authorized request needs them.
|
|
|
|
## Namespacing
|
|
|
|
To prevent cross-contamination, every record in the storage is namespaced by its Vault and Provider.
|
|
|
|
This means multiple accounts for the same provider (e.g., a personal and a work GitHub account) can exist safely within the same Vault as separate connections, or completely isolated if they belong to different Vaults and Principals.
|