Enterprise Login, Teams, OAuth 2.0, and OpenID Connect (OIDC)
Turn an enterprise sign-in into a current organization-and-team context, then distinguish platform login from machine and human connector delegation.
The enterprise problem and today’s slice
Enterprise problem: Northstar's HelixWorks Supplier Onboarding Agent can authenticate Alice yet still expose the wrong team or connector when a signed login token is mistaken for current authorization, leaving stale or cross-tenant access active.
Whole-course context: The previous identity slice produced typed subjects and an intersection rule; today supplies a verified human, one current active team, and separately governed machine and human connector grants for later runs.
Today’s slice: We cover OpenID Connect (OIDC) or Security Assertion Markup Language (SAML) login, just-in-time (JIT) or System for Cross-domain Identity Management (SCIM) lifecycle input, organization and team resolution, generated-app subject mapping, admin-provisioned workload access, and optional user-delegated OAuth without collapsing their owners.
End-of-day evidence: Acme can review paired login, team-isolation, workload-grant, and user-consent probes with actor, resource, scope, precondition, expected result, observed result, environment, timestamp, revision, and immutable trace IDs.
Still unsolved: Run admission, per-tool argument policy, high-risk approval, production connector execution, and continuous revocation remain outside this slice.
Thesis: Enterprise login proves who arrived; safe access appears only after the platform resolves current team authority and then selects a separately owned connector grant for the requested mode.
Smallest complete model: Authenticate the person, resolve current operating context, then select explicit downstream authority. A token can enter the first box without satisfying either later box.
For Northstar, Alice signs in through the corporate identity provider (IdP), selects Procurement, and opens the HelixWorks Supplier Onboarding Agent. Only then may the platform use either Procurement's service grant for scheduled work or Alice's personal grant for an on-behalf-of action.
Customer outcome and implementation focus
The customer outcome is a reliable, reviewable implementation of 05 enterprise login teams oauth oidc. This day introduces the mechanism before policy detail and evidence review; it does not repeat the same customer stories in prose, tables, and diagrams.
Components in focus
Authorization policy service owns decisions; the connector/runtime gateway owns enforcement. Compute: API and isolated worker processes. Storage: PostgreSQL is authoritative for grants and state; Redis is a versioned cache; vault owns secrets; object storage retains redacted evidence only.
Implement the mechanism
Implement the day’s boundary with a current, explicit decision before privileged compute or a downstream call. Bind every effect to a tenant, subject or workload, deployment, resource, and short-lived evidence ID; a cache or model response never grants authority.
Failure modes, trade-offs, and decision rules
The hardest failures are tempting shortcuts that work in a demo and become invisible authority bridges in production. Acme should choose the narrowest mechanism that preserves the required operating mode.
Reusable decision rule: Authenticate from verified protocol evidence, authorize from current owner state, and select exactly one independently revocable downstream grant for the requested operating mode.
| Tempting shortcut | Why it fails | Trade-off | Reusable decision rule |
|---|---|---|---|
| Trust groups embedded in a long-lived login token | Team transfer or SCIM removal is stale until token expiry | Current lookup adds latency and availability dependency | Cache only with a version and bounded freshness; reload for sensitive actions |
| Join people by email | Email changes or is reassigned | Stable protocol subjects require migration handling | Join on provider ID plus immutable protocol subject; treat email as profile data |
| Use Alice’s refresh token for schedules | Automation dies or overreaches when Alice leaves | Service grants reduce personal attribution | Use team-owned service authority for unattended work; preserve initiating/configuring actors in audit |
| Treat app role as connector permission | App owner may not own source data | Separate consent adds product steps | Require explicit connector grant after app authorization |
| Union all team memberships | One request gains unrelated team authority | Explicit team selection adds one product choice | One primary team per operation; deny missing or foreign selection |
Implementation and verification
Implementation can appear correct while negative paths never reach the intended boundary, so Acme must build from owner state outward and verify each bridge independently.
- Configure OIDC Authorization Code with PKCE or SAML using exact issuer, audience, callback, signing, time, correlation, and replay checks.
- Normalize
(identity_provider_id, protocol_subject)into one principal; process JIT or SCIM events idempotently and version membership. - Require an explicit active team and load current membership before creating app subject, tenant, membership, role, and session context.
- Provision and probe the Marketing service grant before enabling Alice’s optional personal consent.
- Keep refresh tokens or client credentials in Vault; send only opaque references to brokers and no secret to browser, model, prompt, app state, or logs.
- Record paired allows and denials: wrong issuer, stale member, Finance
board:42, human-token-as-workload, wrong audience, and post-revocation exchange.
The proof fails if any denial also breaks its unaffected control. For example, a Finance denial is meaningful only if Marketing succeeds in the same environment and trace window.
Implementation reviews should check OpenID Connect Core 1.0 for relying-party and ID-token validation, RFC 9700 for OAuth security practice, RFC 8693 for token-exchange subject, actor, and audience semantics, RFC 7644 for SCIM lifecycle operations, and SAML 2.0 Core for assertion conditions and protocol messages.
Practical next action and falsifiable evidence
A design review without executable probes leaves Acme unable to distinguish isolation from a broken integration. The next action is to run one compact evidence matrix against the HelixWorks Supplier Onboarding Agent before any run-token work begins.
Run Alice’s valid Marketing login, wrong-issuer login, Finance same-ID request, valid service read, human-token substitution, valid personal read, and post-consent-revocation read. Seal actor, resource, scope, precondition, expected, observed, environment, timestamp, owner revisions, and immutable trace IDs for every row.
The thesis is falsified if a signed login alone reaches an app tenant, if multiple team memberships union silently, if a human token satisfies workload identity, if a service grant becomes Alice’s authority, or if revoking one grant disables or preserves the wrong paths. Passing evidence shows one authenticated person, one current context, and one explicitly selected downstream authority at a time.
HelixWorks repository lab
Start at the controller contract rather than parsing identity inside business logic. packages/contracts/src/http.ts defines normalized session facts:
export const requestContextSchema = z.object({
tenantId: tenantIdSchema,
subjectId: z.string().min(1).max(128),
roles: z.array(z.string().min(1).max(80)).max(32),
correlationId: z.string().uuid(),
});
An OIDC adapter should translate validated issuer claims and Northstar's selected team into this shape; arbitrary token claims must not become roles. Zod interprets the boundary, the controller receives validated software state, CPU verifies fields, and a later decision ID is evidence. Translation is an adapter responsibility (SRP); controllers share one schema (DRY); injected identity and membership ports keep use cases independent of an IdP (IoC/DI); MVC keeps cookies and redirects out of domain rules.
pnpm --filter @helixworks/contracts test
Probe a valid Northstar issuer with an unauthorized active team, an expired session with a still-valid group claim, and a valid session with current membership. The first two must deny and the last allow. Any implicit “first team” fallback falsifies the model.