This page is a mapping of library features to the Trust Services Criteria. theAuth does not hold a SOC 2 report, and nothing here states or implies certification or an audit result.
Disclaimer
A SOC 2 report is issued by an independent auditor about a service organization’s entire system, not about a single component or library. theauth-go is a Go authentication library. It provides controls, audit evidence, and enforcement points, but it cannot:
- Author or enforce the operator’s access-review processes.
- Generate the operator’s System Description (SD-1) or Management’s Assertion.
- Substitute for the operator’s change-management procedures, vendor management program, or incident response plan.
- Guarantee the operator’s data center, network, or hosting environment meets any criterion.
An auditor will assess whether the operator has implemented the controls listed in the “What the operator must implement” sections below.
CC1 — Control Environment
CC1.1 — Board/Management Oversight of Controls
What SOC 2 requires: The entity demonstrates a commitment to integrity and ethical values.
How theauth-go helps: Not directly addressable by a library. theauth-go is open-source; the codebase is available for inspection.
What the operator must implement: Governance structure, code of conduct, and management review.
CC1.2 — Board Independence and Oversight of Internal Control
What SOC 2 requires: Board exercises oversight responsibility for the design and operation of internal controls.
How theauth-go helps: Not directly addressable. No library control maps here.
What the operator must implement: Board-level governance and oversight process.
CC1.3 — Management Structure and Reporting Lines
What SOC 2 requires: Management establishes reporting lines and appropriate authorities and responsibilities.
How theauth-go helps: Not directly addressable.
What the operator must implement: Organizational chart, ownership assignments, and escalation procedures.
CC1.4 — Commitment to Competence
What SOC 2 requires: The entity demonstrates a commitment to attract, develop, and retain competent individuals.
How theauth-go helps: Not directly addressable.
What the operator must implement: Hiring, training, and retention policies.
CC1.5 — Accountability for Internal Control Responsibilities
What SOC 2 requires: The entity holds individuals accountable for their internal control responsibilities.
How theauth-go helps: The RBAC subsystem (internal/rbac/) assigns specific permissions (e.g., sessions:revoke, scim:admin) to named roles. Permission grants are audit-logged with role.granted and role.revoked events, providing evidence of who held which access and when.
What the operator must implement: Process for periodically reviewing role grants and removing stale access.
What SOC 2 requires: The entity uses quality information to support the functioning of internal controls.
How theauth-go helps: Audit events include user ID, session ID, IP address, user agent, event type, and structured metadata, giving operators the raw material for quality reporting.
What the operator must implement: Tooling (SIEM, dashboards) to query and aggregate theauth-go audit events.
CC2.2 — Internal Communication
What SOC 2 requires: The entity internally communicates information, including objectives and responsibilities.
How theauth-go helps: Not directly addressable.
What the operator must implement: Security policy documentation, runbooks, and internal communication channels.
CC2.3 — External Communication
What SOC 2 requires: The entity communicates with external parties about matters affecting the functioning of internal controls.
How theauth-go helps: SECURITY.md provides a vulnerability disclosure process. The library emits structured error codes (defined in internal/models/errors.go) that can be surfaced to end users without leaking implementation details.
What the operator must implement: Privacy notice, terms of service, security contact page.
CC3 — Risk Assessment
CC3.1 — Specification of Objectives
What SOC 2 requires: The entity specifies objectives clearly enough to enable identification of risks.
How theauth-go helps: This threat model document specifies the library’s security objectives per component. Each STRIDE entry documents residual risk for operator action.
What the operator must implement: Operator-level security objectives aligned with their specific deployment context.
CC3.2 — Risk Identification and Analysis
What SOC 2 requires: The entity identifies risks to the achievement of its objectives and analyzes them.
How theauth-go helps: The threat model is the risk analysis artifact for the authentication subsystem. Per-component STRIDE tables map each risk to a mitigation or a residual risk for operator action.
What the operator must implement: Risk register covering risks outside theauth-go (infrastructure, supply chain, business logic, third-party processors).
CC3.3 — Fraud Risk Assessment
What SOC 2 requires: The entity considers the potential for fraud in assessing risks to achieving its objectives.
How theauth-go helps: Refresh token family revocation on replay (internal/as/token.go) and SCIM last_used_at tracking (internal/scim/service.go) help against credential abuse. Since v2.6.0 password signin is gated by a login throttle on by default (per client IP and email backoff, plus a per-user lockout). The audit subsystem provides a stream of authentication events for anomaly detection.
What the operator must implement: Anomaly detection rules in their SIEM, and a shared LoginThrottleStore if more than one process serves signin (the default store is per process).
CC3.4 — Significant Changes
What SOC 2 requires: The entity identifies and assesses changes that could affect the system of internal controls.
How theauth-go helps: CHANGELOG.md documents changes per release, with upgrade notes first for behavior changes. Release artifacts are signed and carry an SBOM and provenance attestation (see releases). The operator pins the library version in go.mod.
What the operator must implement: Dependency update process, change-management approval gates, and a test suite that validates authentication behavior on library upgrades.
CC4 — Monitoring Activities
CC4.1 — Ongoing and Separate Evaluations
What SOC 2 requires: The entity selects and develops ongoing or separate evaluations to verify controls are present and functioning.
How theauth-go helps:
- Built-in observability hooks (spans, counters, histograms) are surfaced through the
Hooks interface (observability.go). Operators wire these to OpenTelemetry-compatible backends.
- The OTLP audit sink (
audit/sinks/otlp/) streams events to any OTLP-capable collector for ongoing monitoring.
- Race-detector test suite (
go test -race) is part of CI.
What the operator must implement: Alerting rules on anomalous authentication rates, failed MFA counts, and unexpected role grants.
CC4.2 — Evaluation and Communication of Deficiencies
What SOC 2 requires: The entity evaluates and communicates internal control deficiencies.
How theauth-go helps: SECURITY.md provides a vulnerability disclosure path. Critical deficiencies are tagged in CHANGELOG.md.
What the operator must implement: Internal process for receiving, triaging, and remediating reported deficiencies; SLA for patching critical vulnerabilities.
CC5 — Control Activities
CC5.1 — Controls to Mitigate Risks
What SOC 2 requires: The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives.
How theauth-go helps: The following table maps key risks to theauth-go controls.
CC5.2 — Controls over Technology
What SOC 2 requires: The entity deploys control activities through policies and procedures that address technology-related risks.
How theauth-go helps:
- Session cookies are
HttpOnly, SameSite=Lax; Secure flag enabled via SecureCookie=true, or per request for an https BaseURL, TLS connections and trusted proxies sending X-Forwarded-Proto: https. Cookie-authenticated mutating requests with a foreign Origin are refused with 403 unless listed in Config.TrustedOrigins.
- All sensitive comparisons use
crypto/subtle.ConstantTimeCompare (internal/as/token.go; internal/clientauthcache/cache.go).
- TOTP secrets are AES-256-GCM-encrypted at rest (
internal/totp/service.go).
What the operator must implement: TLS configuration at the edge, secret rotation policy for the TOTP encryption key and JWKS signing keys.
CC5.3 — Policies and Procedures
What SOC 2 requires: Management establishes policies and procedures to achieve objectives.
How theauth-go helps: Provides configurable policy knobs: RequireState (CSRF protection), RateLimitPerIP, RateLimitPerEmail, LoginThrottle, PasswordPolicy, RefreshTokenTTL, SessionTTL, MagicLinkTTL, SecureCookie, TrustedOrigins.
What the operator must implement: Documented policy choices (which knobs are enabled and why), change-management approval to modify them.
CC6 — Logical and Physical Access Controls
CC6.1 — Logical Access Controls
What SOC 2 requires: Restrict logical access to information assets based on authorization.
How theauth-go helps:
- The RBAC subsystem (
internal/rbac/) enforces authorization on every admin endpoint. Permissions are checked before handler logic executes (internal/admin/handlers.go).
- Agent identity flow scopes machine credentials to a specific owner and scope list (
internal/agent/service.go).
- Delegation chains limit agent-on-behalf-of scope to the intersection of all delegators’ scopes (
internal/delegation/service.go).
What the operator must implement:
- RBAC policy authoring: the library enforces; the operator defines which permissions exist and who holds which roles.
- Periodic access review: the audit log surfaces
role.granted and role.revoked events; the operator must review them on a defined cadence.
Audit evidence theauth-go provides: audit_events rows for role.granted, role.revoked, agent.suspended, agent.revoked. (There is no user.suspended event: the library has no user-suspension state to emit it for — see CC6.2 and CC7.4.)
CC6.2 — Provisioning and Deprovisioning
What SOC 2 requires: Access is provisioned and deprovisioned in accordance with established policies.
How theauth-go helps:
- Admin-driven user invitation is audit-logged (
user.invited). Self-service signup (password, magic link, OAuth, SAML) is audit-logged via user.login on first sign-in; there is no separate user.created event.
- Organization removal is exposed via the
removeUser admin handler (internal/admin/handlers.go), audit-logged as organization.member.removed. This removes org membership only — it does not delete or suspend the user account (see CC7.4).
- Agent provisioning (
CreateAgent, MintAgentCredential) and deprovisioning (SuspendAgent, RevokeAgent) are fully audit-logged.
- SCIM 2.0 provisioning support for automated IdP-driven user lifecycle (
scim.user.create, scim.user.patch, scim.user.delete audit events).
What the operator must implement: Offboarding runbook that triggers user suspension/removal, integration with HR system or IdP lifecycle events.
CC6.3 — Role-based Access
What SOC 2 requires: Access to system components is based on roles and responsibilities.
How theauth-go helps:
- Roles are organization-scoped. Each role carries a set of named permissions from a predefined catalog (
internal/rbac/service.go).
- Custom roles can be created with any subset of the permission catalog; unknown permission names are rejected at role creation time (
internal/rbac/service_rbac_catalog_test.go documents this behavior).
What the operator must implement: Definition of roles matching their least-privilege requirements; regular role review.
CC6.4 — Restriction of Access to Privileged Accounts
What SOC 2 requires: Access to privileged accounts is restricted and monitored.
How theauth-go helps:
- The
users:admin, sessions:revoke, agents:admin, and scim:admin permissions are distinct; each requires an explicit role grant.
- Admin handler endpoints require both authentication and the appropriate permission (
internal/admin/handlers.go).
- All admin actions are audit-logged.
What the operator must implement: Separation of duties (e.g., the person who creates roles should not be the same person who grants them); MFA requirement for users holding admin permissions.
CC6.5 — Identification and Authentication
What SOC 2 requires: The system identifies and authenticates users before allowing access.
How theauth-go helps:
- Supports password + TOTP (
internal/password/, internal/totp/), WebAuthn (internal/webauthn/), magic link (internal/magiclink/), OAuth social login (internal/oauth/), and SAML (internal/saml/).
- MFA step-up is enforced before any identity-merge or privilege-escalating operation (
internal/identitylink/service.go).
- Session tokens are 32-byte crypto/rand values, stored as SHA-256 hashes.
What the operator must implement: MFA enrollment requirement for privileged users; session revocation on suspected compromise.
CC6.6 — Network Access Restrictions
What SOC 2 requires: Logical access controls restrict network access to the system.
How theauth-go helps:
- CIMD metadata URL fetches are restricted to HTTPS and a
TrustPolicy-approved host list (internal/cimd/service.go). Since v2.6.0 the fetch client also refuses loopback, private, link-local and similar addresses at dial time and never follows redirects (CIMDConfig.AllowPrivateNetworks is a development opt-in).
- The library does not open inbound ports. Outbound connections go to operator-configured destinations: audit sinks, the email sender, OAuth and SAML identity providers, CIMD and JWT-bearer metadata or key fetches, and the optional breach-password checker.
What the operator must implement: Network perimeter controls (firewall rules, VPC policies) to restrict who can reach the authentication endpoints.
CC6.7 — Transmission Integrity and Confidentiality
What SOC 2 requires: The system protects against unauthorized transmission of information.
How theauth-go helps:
- Session cookies are
Secure when SecureCookie=true or when the request arrives over TLS or an https BaseURL applies (preventing transmission over non-HTTPS).
- Default logs carry no email addresses (v2.7.0); lines use a
user_id or a hashed email_ref.
- Passwords and secrets are never logged; the audit redactor strips them before any sink receives the event (
internal/audit/redact.go).
- Webhook payloads are HMAC-SHA256 signed to ensure transmission integrity (
audit/sinks/webhook/webhook.go).
What the operator must implement: TLS 1.2+ on all external endpoints; HSTS headers; certificate pinning where appropriate.
CC6.8 — Physical Access Controls
What SOC 2 requires: Physical access to facilities and system components is restricted.
How theauth-go helps: Not addressable by a library.
What the operator must implement: Data center physical access controls (badge, biometric, visitor logs).
CC7 — System Operations
CC7.1 — Configuration Management
What SOC 2 requires: The entity obtains, generates, and uses quality information to support operations.
How theauth-go helps:
- Configuration is centralized in the
Config struct (theauth.go); all security-relevant fields have documented defaults.
- Default values are documented:
SessionTTL=24h, MagicLinkTTL=15m, CookieName="theauth_session".
What the operator must implement: Configuration version control; diff-tracking of security-relevant config changes.
CC7.2 — Monitoring of System Components
What SOC 2 requires: The entity monitors system components for anomalies.
How theauth-go helps:
- OpenTelemetry spans and metrics are emitted through the
Hooks interface for every major operation.
- Specific metrics:
theauth_rate_limit_blocked_total, per-grant-type token counters, and span timing.
- Audit events provide a structured log of authentication successes and failures.
What the operator must implement: Alerting thresholds; SIEM correlation rules; on-call escalation paths.
CC7.3 — Evaluation of Security Events
What SOC 2 requires: The entity evaluates security events to determine whether they represent a threat.
How theauth-go helps:
- Audit events carry structured metadata (user ID, IP, user agent) enabling correlation.
- SIEM sinks (OTLP, Splunk HEC, webhook) support streaming to a central security analytics platform.
What the operator must implement: Threat detection rules; incident triage process.
CC7.4 — Response to Identified Security Incidents
What SOC 2 requires: The entity responds to identified security incidents.
How theauth-go helps:
revokeSession provides immediate session-level containment (internal/admin/handlers.go). There is no library-level SuspendUser: the User model and Storage interface have no suspension state, so account-level containment beyond revoking sessions is an operator-built control (see the GDPR page, Article 18).SuspendAgent and RevokeAgent provide immediate machine-credential containment (internal/agent/service.go).- Session revocation is audit-logged with
session.revoked events.
What the operator must implement: Incident response playbooks; breach notification procedures.
CC7.5 — Recovery from Identified Security Incidents
What SOC 2 requires: The entity recovers from identified security incidents.
How theauth-go helps:
ResumeAgent restores a suspended agent after containment investigation (internal/agent/service.go).- JWKS key rotation can be triggered manually to replace potentially compromised signing keys.
What the operator must implement: Business continuity and disaster recovery plans; DB backup and restore procedures.
CC8 — Change Management
CC8.1 — Change Management Process
What SOC 2 requires: The entity authorizes, designs, develops, tests, approves, and deploys changes.
How theauth-go helps:
- All changes are tracked in CHANGELOG.md and the releases page.
- CI runs
go vet and go test -race on pull requests. A benchmark regression gate exists but runs only on manual dispatch and a weekly schedule, not before merge (see benchmarks).
- The stability policy documents the stability guarantees and breaking-change policy.
What the operator must implement: Operator-side change management: staging environment, approval gates, rollback plans for theauth-go version upgrades.
CC9 — Risk Mitigation
CC9.1 — Vendor and Business Partner Risk Management
What SOC 2 requires: The entity identifies, assesses, and mitigates risks associated with vendors and business partners.
How theauth-go helps:
- Dependency versions, including the SAML and XML signature libraries, are pinned in
go.mod and go.sum; Dependabot is configured for updates.
- theauth-go makes no outbound calls of its own; every outbound destination is operator-configured (see CC6.6).
What the operator must implement: Software supply-chain assessment (e.g., go mod verify, SBOM generation, vulnerability scanning via govulncheck).
CC9.2 — Business Disruption and Recovery Risk Management
What SOC 2 requires: The entity assesses and manages risks associated with business disruption.
How theauth-go helps:
- Memory store for development and testing; Postgres, MySQL and SQLite stores for persistence. Availability and replication are properties of the operator’s database.
- Session expiry and refresh token TTL are configurable to match recovery objectives.
What the operator must implement: Multi-AZ database deployment; connection pool fallback; session state recovery procedures.
A1 — Availability
A1.1 — Capacity Planning
What SOC 2 requires: The entity maintains, monitors, and evaluates current processing capacity.
How theauth-go helps:
- A benchmark suite (
internal/bench/) and a benchstat-based regression script (benchgate/, scripts/bench-gate.sh) exist. They run on demand and weekly, no throughput figures are published, and the operator needs their own load tests.
What the operator must implement: Load testing, capacity forecasting, and autoscaling policies.
A1.2 — Environmental Protections
What SOC 2 requires: Environmental controls protect against environmental threats.
How theauth-go helps: Not addressable by a library.
What the operator must implement: Data center environmental controls (power redundancy, cooling, fire suppression).
A1.3 — Recovery Plan Testing
What SOC 2 requires: Recovery plan testing demonstrates the ability to recover from business disruption.
How theauth-go helps:
- theauth-go’s stateless validation path (resource server / mcpresource) is resilient to AS downtime during the JWKS cache TTL window.
What the operator must implement: Documented and tested disaster recovery runbooks; tested DB restore procedures.
C1 — Confidentiality
C1.1 — Confidentiality Policies
What SOC 2 requires: The entity identifies and maintains confidential information per commitments.
How theauth-go helps:
- Secrets (passwords, TOTP keys, session tokens) are never stored in plaintext.
- Audit redactor removes secret-class keys from all event metadata at emission time (
internal/audit/redact.go).
SecureCookie=true prevents session tokens from traversing non-HTTPS channels.
What the operator must implement: Data classification policy; encryption-at-rest for the database; key management procedures.
PI1 — Processing Integrity
PI1.1 — Processing Completeness and Accuracy
What SOC 2 requires: Processing is complete, valid, accurate, timely, and authorized.
How theauth-go helps:
- Storage adapters implement each mutation as a single storage call; multi-step operations such as
MergeAccounts are not one transaction. A failure partway through a merge is safe to retry with the same IDs (see CHANGELOG, v2.5.0).
- SCIM provisioning uses upserts keyed by
externalId.
- Token issuance emits a structured audit event.
What the operator must implement: Data validation at the application layer above theauth-go; reconciliation jobs for SCIM sync.
P — Privacy
P1.1 — Privacy Notice
What SOC 2 requires: The entity provides notice to data subjects about the collection and use of personal information.
How theauth-go helps: Minimal. The library collects email, optional name, IP, user agent, and auth event data (see the GDPR page for the full inventory).
What the operator must implement: Privacy notice (DPN) published at a discoverable URL, listing all data fields collected by theauth-go on the operator’s behalf.
What SOC 2 requires: Personal information is collected only for the purposes identified in the privacy notice.
How theauth-go helps: The library collects only what is needed for authentication: email (identifier), optional name/avatar, hashed password, session metadata (IP, user agent), OAuth provider links, and WebAuthn credentials.
What the operator must implement: Ensure no additional personal data is collected via custom audit metadata without a corresponding DPN update.
What SOC 2 requires: Personal information is used only for the purposes identified in the privacy notice.
How theauth-go helps: Personal data stored by the library is used solely for authentication and session management. No marketing, analytics, or profiling use is embedded in the library.
What the operator must implement: Ensure application-layer code does not repurpose theauth-go data for undisclosed purposes.
What SOC 2 requires: Personal information is disclosed only to authorized parties.
How theauth-go helps:
- Audit sinks forward event data to operator-configured destinations only.
- CIMD fetches go outbound to HTTPS hosts approved by the operator’s
TrustPolicy only.
- The library sends no telemetry. Personal data leaves the process only through operator-configured integrations (audit sinks, email sender, identity providers, and the optional breach checker, which sends a hash prefix).
What the operator must implement: DPAs with audit sink destinations (Splunk, OTLP collector vendor, webhook receiver) before enabling those sinks.
What SOC 2 requires: Personal information is accurate, complete, and relevant.
How theauth-go helps:
UpdateUser (internal/admin/handlers.go) supports correction of name and email.- SCIM PATCH operations support incremental attribute updates.
What the operator must implement: User-facing profile update interface; validation on updated fields.
P8 — Monitoring and Enforcement
What SOC 2 requires: The entity monitors compliance with its privacy commitments.
How theauth-go helps:
- Audit events for every authentication action enable compliance monitoring.
- Data-access primitives (
UserByID, session listing, listOAuthAccounts, QueryAuditEvents, etc.) that an operator can assemble into export and erasure endpoints exist (see the GDPR page, Section 2). These are building blocks, not ready-made export/erasure endpoints: the library does not ship a data-subject export API, and erasure (Article 17) is an explicit operator gap because there is no DeleteUser method on the Storage interface.
What the operator must implement: Privacy compliance reviews; data subject request intake process; retention policy enforcement; the export and erasure endpoints themselves (see COMPLIANCE-GDPR.md, Section 2, “Operator gap”).
What theauth-go Does NOT Provide
This section is explicit about the gaps that an operator’s SOC 2 scope must cover independently.
- System Description (SD-1). The operator writes this; it covers their entire system.
- Management’s Assertion. Signed by the operator’s management, not the library authors.
- Physical security controls. Data center, office, and device controls are entirely the operator’s responsibility.
- Vendor and supply-chain assessment. The operator must assess theauth-go and all other dependencies.
- Incident response and business continuity plans. The library provides containment primitives (suspend, revoke); the plans are the operator’s.
- User training and awareness programs. The library cannot enforce security culture.
- Audit of operator’s own code. theauth-go secures authentication; the operator’s application code wrapping it is not in scope for this document.
- Penetration testing. The library has been designed with the threats in the threat model in mind, but periodic external penetration testing of the operator’s deployed system is the operator’s responsibility.
Last modified on October 7, 2026
