Google sign-in, centralized MFA and a shared identity path for client applications

What centralized multi-factor authentication means for the applications

Centralized authentication gives the portfolio one deliberate place to verify identity. When a protected application receives a visitor who is not signed in, it redirects that visitor to auth.autosecurelogin.com. The identity service verifies the account password and the required second factor, then returns the user to the original protected destination. The first protected destination is the portfolio command center at the main Auto Secure Login domain.

An authenticator app supplies time-based one-time passwords, often called TOTP codes. The identity service can also support passkeys as a strong recovery or sign-in option. This does not automatically place a login wall in front of every product. Public-interest resources, product information, legal pages and search-oriented guides can remain public. Account areas, staff portals and administrative tools can be connected one at a time after compatibility, privacy boundaries, recovery processes and operational ownership have been reviewed.

The new software portfolio dashboard turns scattered work into an operating view

A growing custom software portfolio can become difficult to manage when every application has its own hosting status, repository, legal page, release stage and next action. The private dashboard currently tracks eighteen relevant programming projects and thirty-nine reviewed tasks. It checks public application availability and allow-listed server services, then combines that live information with a curated project queue. Obvious non-programming work is excluded so the view stays focused on software delivery.

The dashboard covers Auto Secure Login, StubSafe, Aya, Outside Access, ASL Direct, Policy Lens, SOMB and DORA complaint guidance, APMSG, Pillow Pair, Kavanah Journal, HomelessHelper, Doctor and NPI Search, Repo Runner, Sentinel, ASL Tunnel and the Playwright Selector Toolkit. Each card explains the product, links to its application and repository when appropriate, shows whether central authentication is active or planned, and lists concrete work that still needs attention.

Current priorities are visible without pretending every project is finished

The command center separates a healthy public response from the work required for a dependable release. StubSafe’s pay stub application and payroll-rules service need stability review before account integration moves forward. APMSG needs its messaging application restart behavior diagnosed and then requires a complete consent and delivery test. Kavanah Journal needs its inactive service reviewed along with production authentication and backup recovery. These are operational facts, not marketing claims, and making them visible helps prevent premature release decisions.

The queue also records production-readiness work that is not represented by a simple green health check. ASL Direct still has provider activation, supervised-call testing, operational ownership, privacy and legal review, Android signing and backup validation work. Sentinel has a documented production activation checklist for the next continuous-monitoring release. Outside Access, Repo Runner, Pillow Pair, HomelessHelper and the public data tools each have recurring backup, data-quality, messaging or release-verification responsibilities.

Security comes from layered controls, not a single login screen

The dashboard listens only on the Droplet’s loopback interface and is published through the existing HTTPS web server. The web server asks the identity service to authorize every dashboard request, including JavaScript and style assets, before it forwards the request. The application itself also refuses requests that do not contain a verified proxy identity. This defense-in-depth design reduces the chance that a route or static asset will accidentally bypass the login requirement.

The interface is deliberately read-only. It cannot restart services, edit tasks, open private logs or change deployment settings. That keeps the first integration useful without turning a new web page into a remote-control surface. The public development post documents the architecture and business value while excluding account credentials, authenticator seeds, private keys, customer data, internal network details and protected source-code decisions.

What comes next for authentication and portfolio operations

The next authentication task is to add reliable account-recovery email through a dedicated mail credential, then register a passkey as a backup factor and test encrypted identity-database recovery. After those foundations are verified, one controlled operational application can become the next pilot. Repo Runner or Outside Access are reasonable candidates because their authorized-user workflows benefit from consistent sign-in, but the final choice should follow an application-level compatibility and role review. The Command Center now includes a direct Change password link to the account security screen, and a direct visit to the identity portal uses the Command Center as its default post-login destination.

Pillow Pair is now the first registered client pilot and can move to its Better Auth connection next. StubSafe, APMSG and Kavanah Journal can follow after their service and account flows are stable. Public tools such as HomelessHelper, Doctor and NPI Search, Policy Lens and Aya do not need to force a login for ordinary public use. The useful pattern is selective protection: keep educational and discovery content accessible, protect personal or operational data, and give administrators one place to understand the portfolio before deciding what to build or repair next.

A shared client identity broker prepares Google sign-in without breaking the staff login

The existing staff login remains the right tool for protecting administrative routes through the web proxy, but it is not designed to use Google as an upstream identity provider. Instead of replacing a working two-factor login or copying a Google client secret into every product, Auto Secure Login now has a separate OpenID Connect identity broker under the same authenticated domain. The broker gives account-based applications a standards-based issuer, authorization endpoints and role model while the current Command Center login continues unchanged.

The Google sign-in connection is deliberately split into a public platform foundation and a private Google Cloud credential. The identity endpoint and client rollout plan can be deployed and tested without exposing a secret. To accept real Google users, the Google Cloud project owner must create one Web application OAuth client, use the broker callback URL exactly, and provide only the basic openid, email and profile scopes. The client ID and client secret belong in protected server configuration, not in a repository, blog post, screenshot or browser source.

This model also supports more than one sign-in choice. Client accounts can use passkeys, authenticator-app codes and recovery codes, while organizations that need their own identity provider can later connect Microsoft Entra ID or another OpenID Connect or SAML service. Email and password registration remains staged until recovery email, terms acceptance and support procedures are ready. SMS is not the default security factor because stronger phishing-resistant and app-based options are available.

Pillow Pair is the first registered client application in the new realm. Its confidential server-side client uses an exact callback address and requires PKCE with the S256 challenge method. The generated client credential is stored only in protected server configuration. Connecting the existing Better Auth account interface is the next source change. StubSafe and APMSG remain behind service-repair gates, while Kavanah Journal is healthy and its identity work stays queued behind recovery and backup review.

Tunnel dashboard protection and fresher operational reporting

The ASL Tunnel dashboard is now linked directly from the private Command Center and protected by the same administrator two-factor boundary used for platform operations. An unauthenticated visit redirects to the central staff login before any Tunnel controls are shown. This keeps the operational console available from one place without making it a public management surface.

The Command Center now monitors both parts of the shared identity foundation: the existing staff authentication service and the OpenID Connect client identity broker. It also displays the protected platform-administrator, staff, client and application groups so future integrations can receive narrowly scoped roles instead of a general all-access account. Tunnel uses the staff administrator boundary today, while compatible client applications can adopt the broker as their account flows are reviewed.

The Journal warning was also corrected after a live comparison. Kavanah Journal was active and running with no recorded service restarts, and its public health check returned HTTP 200. A completed service-repair task was still appearing in the priority list because completed high-priority work was not excluded. Completed tasks are now removed from that list, while unfinished release-readiness work remains visible as planned work rather than a false outage.

Live application checks run automatically every 60 seconds. Passive requests may reuse a server snapshot for up to 45 seconds, but the Refresh status button now bypasses that snapshot and performs an immediate check. The page displays both the last-check time and this refresh schedule so operators can tell whether a result is current.