Skip to content
Decision 2 · Sign-in provider test

Let one required feature decide build versus buy

The pass-or-fail rule written before the sign-in provider test, the results table, and the response that ruled the provider out: unsupported scope intel:read.

Quoted verbatim from HYVIRAL’s specifications, code and logs. Internal paths and identifiers are redacted.

The decision

Sign-in for outside assistants had to express what a connected assistant may do: HYVIRAL’s own permission scopes, a branded consent screen, client registration, and discovery metadata with tokens tied to the intended service.

I fixed a testable rule in advance: failure of any mandatory requirement meant building the authorization server in-house. A passing spike would keep the work on resource-server integration and consent branding. Either way, the external MCP contract stayed the same.

Building it in-house keeps HYVIRAL’s permission vocabulary and consent flow under my control, and makes protocol implementation, token handling and security review my engineering responsibility.

From the source

Authorization specification. The decision rule, recorded as locked:

D10 · Locked

Phase 0 default rule: if any of the four AS requirements (custom scopes, branded consent, CIMD or DCR client registration, RFC 8414 metadata with resource audience binding) fails in the spike, build the AS in-house — no further discussion round

The spike ran locally on 21 August 2026 against Supabase CLI 2.115.0 and GoTrue v2.187.0.

Spike result. Discovery and registration passed; the required custom scope failed:

Requirement (D10)Result
RFC 8414 metadataPASS — 404 while disabled, 200 once [auth.oauth_server] enabled = true
CIMD or DCR registrationPASS — a real POST /auth/v1/oauth/clients/register returned 201 with a client_id
Custom scopesFAIL
RFC 8707 resource audienceNot proven, and moot once the scope check failed

The deciding response. The request asked for HYVIRAL’s intel:read scope (ellipses as in the source):

GET /auth/v1/oauth/authorize?…&scope=intel%3Aread
→ 302 …/callback?error=invalid_request&error_description=unsupported+scope%3A+intel%3Aread

What this shows

A requirement, a versioned experiment, a failing response and a decision tied to a rule written before the test. Evidence changed the provider choice while the product-facing contract stayed stable. The result applies to the versions tested.

Back to the case All code & records