Threat model
Threats, scoped honestly
The Go threat model uses STRIDE and covers the library as deployed by an operator in a Go HTTP application. It is a design document, not an audit report or a certification. The document states it was last reviewed against v2.7.0.
Sources and review date
- Source
- theauth-go threat model. It covers theauth-go only.
- Last reviewed
- 2026-10-06. Summaries on this page are written by hand and checked against the linked documents on that date. The documents themselves are the record.
Trust boundaries
Where data crosses a line
The document lists seven boundaries. Each is analyzed per component with a mitigation and a residual risk.
| Boundary | What crosses it | Direction |
|---|---|---|
| HTTP network | OAuth and OIDC protocol messages: authorize, token, introspect, JWKS | Inbound |
| HTTP network | Provider OAuth callbacks (GitHub, Google, Apple and others) | Inbound |
| Process and database | SQL queries and responses | Both ways |
| Process and SIEM | Audit events forwarded to OTLP, Splunk or webhook sinks | Outbound |
| Process and email | Magic link and password reset emails | Outbound |
| HTTPS to identity providers | Client identity metadata document fetches | Outbound, HTTPS only |
| Process memory | Ed25519 signing keys | In process only |
Scope
What is analyzed
Components in scope, per the document:
- Token issuingThe authorization server (authorization code, refresh token, client credentials and token exchange grants) and the resource server validator in mcpresource.
- PersistenceMemory, Postgres, MySQL and SQLite storage backends behind the Storage interface.
- Sign-in flowsPassword, social OAuth, magic link, WebAuthn, TOTP, SAML and SCIM.
- Supporting systemsAudit subsystem, sessions, agent identity, delegation chains, client identity metadata documents and RBAC.
Out of scope: the operator owns these
- TLS termination and certificates. The library warns at startup when cookies are not Secure over non-https, but cannot enforce transport security.
- Secrets at rest. Encryption keys are supplied by the operator. The library has no secret store.
- Infrastructure isolation. Containers, VMs, Kubernetes policies and kernel security modules.
- Authentication device security. A compromised TOTP app, stolen WebAuthn key or compromised phone.
- Network-layer flood protection. The library provides application-layer limits, not TCP or UDP flood defense.
- Runtime side channels. Constant-time comparisons are used, but Go runtime behavior cannot be guaranteed.
- TokensBearer theft and replay, replay across resources, PKCE downgrade, refresh token replay, JWKS rotation races.
- AuthorizationCode injection, open redirect, CSRF on authorize, delegation scope escalation.
- Sessions and sign-inSession fixation, cookie theft, provider OAuth state CSRF, MFA bypass on identity merge, WebAuthn replay, SAML signature wrapping.
- OperationsAudit log tampering, client authentication cache poisoning, SCIM token reuse, webhook signature forgery, client identity trust policy.
Catalog
Numbered threats with a status each
The catalog is a table of numbered entries (T-01 onward). Each has a status, such as mitigated, partially mitigated, or operator responsibility. High-level groups:
Reading it
Some mitigations are opt-in
A mitigation can depend on a setting. For example, requiring state on /authorize is off by default and should be enabled in production, as the security page also says.
The per-component sections give each threat a mitigation and a residual risk, so you can see what you must configure yourself. The full catalog, including every status, is in threat model. Read it rather than this summary when you assess a deployment.
To report a vulnerability, use the process on the security page.
Related pages
Get started
Give your first agent an identity.
Install the package, create an agent with scoped permissions, and read its first audit record. The core runs on Postgres, SQLite, MySQL or D1, and the Go module needs a single go get.
npm install @glinr/theauthgo get github.com/glincker/theauth-go