ADADR: StarIntel OAuth authorization-code provider for Bixby user accounts #144

New issue

Closed

opened 2026-08-24 12:16:51 +00:00 by lost-rob0t · 2 comments

lost-rob0t commented

2026-08-24 12:16:51 +00:00

(Migrated from github.com)

Scope

Create the canonical Auto-Research research + design authority for lost-rob0t/starintel-server#111 / draft PR lost-rob0t/starintel-server#117.

The operator has already explicitly approved research and design for this Bixby auth problem in the controlling interactive session on 2026-08-24. This issue is the durable repository record for that approval and the ADADR evidence; it does not fabricate implementation approval.

Problem

StarIntel has merged OAuth credential/token core, but Bixby user-account linking still requires a real public OAuth 2 authorization-code provider surface. Samsung currently requires concrete authorize/token endpoints in root authorization.bxb, a Developer Center secret-key reference, and a registered Bixby callback. The implementation must support the dual-mode product architecture: guest Intelligence remains public; signed-in Intelligence uses a real StarIntel human principal with read/search scopes; Operations reuses that identity with stronger scopes.

Required research/design

verify current Samsung/Bixby authorization-code syntax and account-linking behavior from current Samsung/Bixby docs;
inspect current starintel-server OAuth core and human-user authentication; do not invent a parallel identity system;
define /oauth/authorize browser/protocol semantics and /oauth/token exchange semantics;
require exact registered redirect URI validation before login;
require S256 PKCE for Bixby authorization-code clients where supported;
preserve opaque state exactly and safely encode redirect output;
authenticate existing StarIntel human_user identity without minting a legacy API key as an intermediate artifact;
issue one-time authorization codes and short-lived OAuth access tokens using the existing OAuth core;
define stable OAuth protocol errors and no-store/no-cache token responses;
never log or return passwords, client secrets, authorization codes after exchange, or bearer tokens except the token endpoint response itself;
keep Samsung/Bixby identity distinct from StarIntel principal identity;
keep guest public-read authority separate from authenticated user authority.

Threat model

At minimum attack:

open redirect / redirect substitution;
authorization-code interception and replay;
PKCE downgrade / verifier mismatch;
CSRF/login swap via lost or rewritten state;
client impersonation / wrong client secret;
scope escalation at authorization or exchange;
cross-user and cross-tenant principal confusion;
silent fallback from invalid authenticated request to guest public data when private access was intended;
bearer/password/client-secret leakage through logs, URLs, errors, fixtures, cache, or redirects;
caching of token-bearing/private responses across users;
token replay/expiry/revocation;
duplicate authorization-code exchange;
public protocol routes accidentally becoming unauthenticated privileged operations;
coupling the provider to Bixby-specific identity semantics or capsule-global service credentials.

Decision target

The expected smallest coherent design is a StarIntel-owned standards-shaped authorization-code provider reusing the merged OAuth core and existing human-user identity. Bixby is one registered client, not the identity owner. Guest Intelligence continues through the synthetic public reader; signed-in Intelligence and Operations use the same StarIntel principal with least-privilege scopes.

Realize gate

Implementation promotion remains TDD-first in starintel-server#117. Its current tests-only RED branch must not be promoted until the canonical research/design documents are present and this explicit operator research/design approval is recorded in their approval tables. Exact-head CI is mandatory before merge.

Current implementation evidence

OAuth core merged in starintel-server PR #115.
Provider draft PR #117 head 8e294e1d374a4a84bac00a12e3d57066aa6bc96e is intentionally tests-first RED.
Current provider tests require public protocol paths, strict redirect/client/scope/PKCE validation, existing-user authentication, state-preserving safe redirect, one-time code exchange, bearer JSON, and Cache-Control: no-store.

No Samsung Simulator, Developer Center client registration, private submission, or Galaxy device validation is claimed.

## Scope Create the canonical Auto-Research research + design authority for `lost-rob0t/starintel-server#111` / draft PR `lost-rob0t/starintel-server#117`. The operator has already explicitly approved research and design for this Bixby auth problem in the controlling interactive session on 2026-08-24. This issue is the durable repository record for that approval and the ADADR evidence; it does not fabricate implementation approval. ## Problem StarIntel has merged OAuth credential/token core, but Bixby user-account linking still requires a real public OAuth 2 authorization-code provider surface. Samsung currently requires concrete authorize/token endpoints in root `authorization.bxb`, a Developer Center secret-key reference, and a registered Bixby callback. The implementation must support the dual-mode product architecture: guest Intelligence remains public; signed-in Intelligence uses a real StarIntel human principal with read/search scopes; Operations reuses that identity with stronger scopes. ## Required research/design - verify current Samsung/Bixby authorization-code syntax and account-linking behavior from current Samsung/Bixby docs; - inspect current `starintel-server` OAuth core and human-user authentication; do not invent a parallel identity system; - define `/oauth/authorize` browser/protocol semantics and `/oauth/token` exchange semantics; - require exact registered redirect URI validation before login; - require S256 PKCE for Bixby authorization-code clients where supported; - preserve opaque `state` exactly and safely encode redirect output; - authenticate existing StarIntel `human_user` identity without minting a legacy API key as an intermediate artifact; - issue one-time authorization codes and short-lived OAuth access tokens using the existing OAuth core; - define stable OAuth protocol errors and no-store/no-cache token responses; - never log or return passwords, client secrets, authorization codes after exchange, or bearer tokens except the token endpoint response itself; - keep Samsung/Bixby identity distinct from StarIntel principal identity; - keep guest public-read authority separate from authenticated user authority. ## Threat model At minimum attack: - open redirect / redirect substitution; - authorization-code interception and replay; - PKCE downgrade / verifier mismatch; - CSRF/login swap via lost or rewritten `state`; - client impersonation / wrong client secret; - scope escalation at authorization or exchange; - cross-user and cross-tenant principal confusion; - silent fallback from invalid authenticated request to guest public data when private access was intended; - bearer/password/client-secret leakage through logs, URLs, errors, fixtures, cache, or redirects; - caching of token-bearing/private responses across users; - token replay/expiry/revocation; - duplicate authorization-code exchange; - public protocol routes accidentally becoming unauthenticated privileged operations; - coupling the provider to Bixby-specific identity semantics or capsule-global service credentials. ## Decision target The expected smallest coherent design is a StarIntel-owned standards-shaped authorization-code provider reusing the merged OAuth core and existing human-user identity. Bixby is one registered client, not the identity owner. Guest Intelligence continues through the synthetic public reader; signed-in Intelligence and Operations use the same StarIntel principal with least-privilege scopes. ## Realize gate Implementation promotion remains TDD-first in `starintel-server#117`. Its current tests-only RED branch must not be promoted until the canonical research/design documents are present and this explicit operator research/design approval is recorded in their approval tables. Exact-head CI is mandatory before merge. ## Current implementation evidence - OAuth core merged in `starintel-server` PR #115. - Provider draft PR #117 head `8e294e1d374a4a84bac00a12e3d57066aa6bc96e` is intentionally tests-first RED. - Current provider tests require public protocol paths, strict redirect/client/scope/PKCE validation, existing-user authentication, state-preserving safe redirect, one-time code exchange, bearer JSON, and `Cache-Control: no-store`. No Samsung Simulator, Developer Center client registration, private submission, or Galaxy device validation is claimed.

lost-rob0t commented

2026-08-24 20:09:43 +00:00

(Migrated from github.com)

RAGE implementation reconciliation (2026-08-24): the authorized STAR-SERVER-042 realization has now merged in lost-rob0t/starintel-server PR #118. Final implementation head: 2c00cda2f2f18424a2279b933322235fee4b15c6; merge commit: 4f2f70126bc59e18681844019460a33709e1eba6. Exact-head required server gates were all green before merge: Smoke Tests run 400, Container Stack run 401, Canonical StarIntel schema lock run 287, and Operational salvage run 232. PR #118 implements the approved provider boundary plus the generic reload-safe add-on/Bixby packaging described by its merged scope. This comment is implementation evidence only; it does not alter or fabricate any approval state. Canonical Org/implementation-ledger reconciliation remains pending because roam/implement/star-server/ is currently occupied by QUASAR-002-clog-hybrid-prototype.org; per repository AGENTS.md, a second active implementation file must not be created manually.

RAGE implementation reconciliation (2026-08-24): the authorized STAR-SERVER-042 realization has now merged in `lost-rob0t/starintel-server` PR #118. Final implementation head: `2c00cda2f2f18424a2279b933322235fee4b15c6`; merge commit: `4f2f70126bc59e18681844019460a33709e1eba6`. Exact-head required server gates were all green before merge: Smoke Tests run 400, Container Stack run 401, Canonical StarIntel schema lock run 287, and Operational salvage run 232. PR #118 implements the approved provider boundary plus the generic reload-safe add-on/Bixby packaging described by its merged scope. This comment is implementation evidence only; it does not alter or fabricate any approval state. Canonical Org/implementation-ledger reconciliation remains pending because `roam/implement/star-server/` is currently occupied by `QUASAR-002-clog-hybrid-prototype.org`; per repository AGENTS.md, a second active implementation file must not be created manually.

nsaspy referenced this issue

2026-08-28 03:23:15 +00:00

ADADR #144: approve Bixby OAuth provider design #145

nsaspy closed this issue

2026-08-29 10:28:04 +00:00

nsaspy referenced this issue

2026-08-29 10:28:04 +00:00

DESIGN_READY_FOR_OPERATOR_REVIEW: Bixby -> central ZITADEL account linking #161

nsaspy commented

2026-08-29 10:28:13 +00:00

Owner

Superseded on the identity-provider ownership decision by #178 / #179. The protocol/threat-model work here remains useful historical material, but Bixby must no longer treat starintel-server as the canonical public human identity provider. Current architecture uses central ZITADEL at auth.starintel.actor (starintel-labs/starintel-infra#74). This does not grant implementation approval.

Superseded on the **identity-provider ownership decision** by #178 / #179. The protocol/threat-model work here remains useful historical material, but Bixby must no longer treat `starintel-server` as the canonical public human identity provider. Current architecture uses central ZITADEL at `auth.starintel.actor` (`starintel-labs/starintel-infra#74`). This does **not** grant implementation approval.