Pillow Pair is the first live OpenID Connect client in the portfolio
Pillow Pair now connects its existing account experience to the shared Auto Secure Login identity service. A web visitor can choose Continue with Auto Secure Login in English or Spanish, move to the central authorization screen and return through the product's registered callback after a successful sign-in. The application asks its own server whether central login is configured before showing the option, which prevents a nonfunctional button from appearing when the protected server setting is unavailable.
The integration uses OpenID Connect discovery, a confidential server-side client, the authorization-code flow and PKCE with the S256 challenge method. The callback is limited to the Pillow Pair web application rather than a broad wildcard. Existing email-and-password access and guest mode remain available, so this pilot adds a shared option without forcing current users into a new account path. Native mobile sign-in remains intentionally gated until a secure system-browser and application-link return flow is implemented and tested.
Delivered in this update
- Bilingual central-login action for the Pillow Pair web application
- Exact callback, OpenID Connect discovery and PKCE protection
- Existing email-and-password and guest access preserved
- Native sign-in held for a dedicated secure callback release
The central account policy adds stronger choices without removing passwords
The shared identity policy keeps a username-and-password account linked to a verified email as the practical baseline. Passkeys, authenticator-app codes and recovery codes are additive security methods. A passkey can be protected by the fingerprint, face check or device PIN already built into a phone or computer, but Auto Secure Login does not collect or store a person's fingerprint, facial image, iris scan or other biometric template. The device performs that local unlock and returns a cryptographic proof instead.
The live identity broker is configured for discoverable passkeys and recovery-code registration while preserving password and authenticator-app alternatives. Public self-registration, email verification and email-based password reset remain launch gates until reliable mail delivery, terms acceptance and support procedures are tested together. This staged approach avoids advertising a recovery path before operators can prove that a user will receive the message and understand the next step.
Delivered in this update
- Password accounts remain available as the baseline
- Optional passkeys, authenticator codes and recovery codes
- No centralized collection of biometric templates
- Public registration and email recovery remain controlled launch gates
A privacy-safe Trust Layer records security events without recording secrets
The platform repository now includes a reusable, versioned audit-event contract for identity lifecycle activity. It can describe events such as account creation, successful or failed authentication, sign-out, password changes, passkey registration, authenticator enrollment and recovery-code use. The same contract reserves compatible receipts for future terms acceptance and messaging consent, allowing products to share one clear evidence format instead of inventing unrelated logs for every application.
The contract rejects passwords, session tokens, one-time codes, authenticator seeds, recovery-code values, raw WebAuthn material and biometric records from event metadata. Identity and administrator events also use limited retention, and detailed administrator representations are disabled. These boundaries make operational evidence more useful while reducing the chance that a diagnostic log becomes a second store of authentication material or sensitive personal information.
Delivered in this update
- Versioned identity audit events shared across compatible products
- Future terms and messaging receipts fit the same evidence model
- Secrets, raw authenticators and biometric records are rejected
- Limited event retention supports practical security review
Live verification separates configured security from user enrollment
The Command Center wording now distinguishes a platform capability from an individual user's completed setup. Passkeys can be configured at the identity service while still requiring each user to register and test a device. Recovery codes can be available while still requiring each account owner to generate, save and test a set. That distinction prevents a green platform indicator from becoming an inaccurate claim that every user has completed recovery preparation.
The Pillow Pair service is running from a versioned release, loads its client identity from protected server configuration and reports central login as enabled. A public initiation test returned an authorization URL for the central broker with the exact Pillow Pair callback and PKCE challenge. The private Google Cloud web OAuth client is now configured, and the public broker page exposes the Google provider. A real-user sign-in and account-linking acceptance test remains before production readiness. Future products will be connected one at a time after their account model, roles, recovery process and service stability are reviewed.
Delivered in this update
- Command Center labels distinguish configuration from per-user testing
- Versioned Pillow Pair deployment passed health and central-login checks
- Authorization initiation verified without completing or exposing a user session
- Google provider configured with real-user acceptance testing still required