mirror of
https://github.com/agentrhq/authsome.git
synced 2026-09-19 01:34:19 +08:00
Manoj Bajaj
54 lines
2.6 KiB
Plaintext
54 lines
2.6 KiB
Plaintext
---
|
|
title: "Daemon trust boundary"
|
|
sidebarTitle: "Daemon trust boundary"
|
|
description: "What the loopback-only daemon model protects against, and what it doesn't."
|
|
icon: "shield"
|
|
keywords: ["authsome daemon security", "loopback bind security", "127.0.0.1 trust", "local daemon access control"]
|
|
---
|
|
|
|
The Authsome daemon binds to `127.0.0.1:7998`. It uses Proof-of-Possession (PoP) tokens to verify that callers belong to a registered Identity. This page explains what that boundary protects.
|
|
|
|
## The model
|
|
|
|
Authsome assumes the local machine is generally trusted, but adds specific checks to isolate credentials:
|
|
|
|
- The OS enforces loopback binding so only traffic from the same host reaches the daemon.
|
|
- The daemon requires a PoP JWT signed by the agent's cryptographic Identity (Ed25519 key) to authorize credential access.
|
|
- That Identity must be bound to a Principal, which owns the Vault.
|
|
|
|
## What the boundary protects against
|
|
|
|
| Threat | Outcome |
|
|
|--------|---------|
|
|
| Network attackers on the LAN | Cannot connect. The daemon binds to 127.0.0.1 only. |
|
|
| Internet attackers | Cannot connect. |
|
|
| Unauthorized agents on the same host | Cannot read credentials. Without the Ed25519 private key to sign the PoP token, the daemon rejects the request. |
|
|
| Tampering with an in-flight OAuth callback | Limited. The callback URL is `127.0.0.1:7998/auth/callback/oauth`. Only same-host traffic can reach it. |
|
|
|
|
## What the boundary does not protect against
|
|
|
|
| Threat | Outcome |
|
|
|--------|---------|
|
|
| A process running as root | Can read the `master.key` and the Vault directly. The daemon is not the bottleneck here. |
|
|
| Memory inspection of the daemon process | Can read decrypted credentials held in active sessions or the proxy's request pipeline. |
|
|
| Cross-session leak after a restart | Active auth sessions are in-memory. A daemon crash mid-flow leaves orphaned state at the provider, but no credential leak locally. |
|
|
|
|
## How to harden inside the boundary
|
|
|
|
You can reduce blast radius even further:
|
|
|
|
- Run a per-user daemon by setting `AUTHSOME_HOME` to a user-specific path. This isolates Vault files across users on the same host.
|
|
- Keep `AUTHSOME_HOME` off shared mounts unless you control every host that mounts it.
|
|
- Watch the Admin Audit Dashboard (at `/audit`) or query `authsome log` for unexpected `revoke`, `register`, or `export` events.
|
|
|
|
## What's next
|
|
|
|
<Columns cols={2}>
|
|
<Card title="Threat model" icon="shield-halved" href="/security/threat-model">
|
|
The full asset list and trust boundaries.
|
|
</Card>
|
|
<Card title="The local daemon" icon="server" href="/concepts/the-daemon">
|
|
What the daemon does and which routes it exposes.
|
|
</Card>
|
|
</Columns>
|