05

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 shortcutWhy it failsTrade-offReusable decision rule
Trust groups embedded in a long-lived login tokenTeam transfer or SCIM removal is stale until token expiryCurrent lookup adds latency and availability dependencyCache only with a version and bounded freshness; reload for sensitive actions
Join people by emailEmail changes or is reassignedStable protocol subjects require migration handlingJoin on provider ID plus immutable protocol subject; treat email as profile data
Use Alice’s refresh token for schedulesAutomation dies or overreaches when Alice leavesService grants reduce personal attributionUse team-owned service authority for unattended work; preserve initiating/configuring actors in audit
Treat app role as connector permissionApp owner may not own source dataSeparate consent adds product stepsRequire explicit connector grant after app authorization
Union all team membershipsOne request gains unrelated team authorityExplicit team selection adds one product choiceOne 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.

  1. Configure OIDC Authorization Code with PKCE or SAML using exact issuer, audience, callback, signing, time, correlation, and replay checks.
  2. Normalize (identity_provider_id, protocol_subject) into one principal; process JIT or SCIM events idempotently and version membership.
  3. Require an explicit active team and load current membership before creating app subject, tenant, membership, role, and session context.
  4. Provision and probe the Marketing service grant before enabling Alice’s optional personal consent.
  5. 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.
  6. 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.