> ## Documentation Index
> Fetch the complete documentation index at: https://authsome.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# The local daemon

> Why Authsome runs a persistent background daemon to broker credentials.

Authsome operates as a persistent local daemon (by default running on `127.0.0.1:7998`). The CLI and the injection proxy act as thin clients that communicate with this daemon.

## Concept and motivation

Authentication flows hold state. They involve asynchronous steps like browser redirects and callbacks. If Authsome were a short-lived CLI tool, these flows would break:

* **OAuth callbacks:** OAuth needs a listening port for the provider's redirect. A CLI exits before you finish logging in.
* **Session state:** Multi-step operations and token refresh logic need a place to live.
* **Secure injection:** The proxy needs an isolated component to fetch fresh tokens without exposing the Vault decryption keys to the proxy process itself.

The daemon solves this. It runs a persistent coordinator that manages browser bridges, handles OAuth callbacks, serves the dashboard, and orchestrates vault access and credential lifecycle.

## Trust boundary and authorization

To ensure that only authorized clients can request credentials from the daemon, Authsome uses **Proof-of-Possession (PoP) JWTs**.

Every request made by the CLI or the proxy to the daemon carries a short-lived JWT signed by the agent's cryptographic Identity (Ed25519 key). The daemon verifies the signature and ensures the Identity is bound to a valid Principal before serving the credential or performing any Vault operation.