Skip to main content
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, in-memory coordinator that manages browser bridges, handles OAuth callbacks, serves the dashboard, and orchestrates the Vault and Auth layers.

​
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.