Team & Access Control

Hardware is expensive and the data produced by hardware tests is often export-controlled, safety-critical, or commercially sensitive. Stout treats access control as a first-class concern, not a bolt-on. Every user belongs to one or more organizations; each organization owns its boxes, workflows, artifacts, and audit logs. Within an organization, teams group boxes and users together so a subsidiary, a contracted vendor, or a specific product line sees only what it should.

Role-based access control assigns each user one of several roles per resource type. Actions are either `read` or `manage`; resources include org, team, box, reservation, job, export, audit log, device, workflow, and factory. The API enforces the check at the pre-handler layer before any business logic runs, so an API route cannot accidentally leak data from a resource the caller is not entitled to. Every mutation is logged through a non-blocking audit event that records actor, resource, action, and correlation ID.

Authentication supports three schemes. Interactive users authenticate via JWT bearer tokens with short-lived access tokens and rotating refresh tokens; refresh tokens are revocable through a Redis-backed blacklist. Boxes authenticate via API keys (`stout_` prefix, 64 hex characters) whose plaintext value is only visible at creation time — Stout stores only the SHA-256 hash. SSO backends cover both OpenID Connect and SAML, including encrypted storage of client secrets and metadata using AES-256.

For teams moving from Okta, Azure AD, Google Workspace, or any OIDC/SAML provider, just-in-time provisioning creates a Stout user on first login and maps group claims to organization roles. Offboarding is a single identity-provider action: the user cannot re-authenticate, their JWTs expire in minutes, and their historical audit entries remain immutable. Combined with per-resource RBAC and box-level maintenance windows, you get the compliance posture a SOC 2 audit actually asks about.