Removal of the "Manual OAuth Token" Setup Method Due to a Fundamental Design Flaw

[jleinenbach]

Hi everyone,

After an in-depth analysis prompted by recurring authentication failures, I've identified a critical, systemic issue with our current setup flow that I believe we need to address.

The Core Problem: Two Types of Tokens, One Flawed Path

The integration's long-term stability relies on a long-lived AAS Master Token. This special token, typically prefixed with aas_et/..., is generated by gpsoauth during the initial, interactive login and is the key to autonomously renewing short-lived service tokens (like ADM and Spot tokens) in the background.

Currently, we offer two setup methods:

1. secrets.json Method: This method, using the external GoogleFindMyTools/main.py script, correctly generates and saves this essential long-lived Master Token. This is the only robust method.

2. "Manual OAuth Token + Email" Method: This method uses a helper script (get_oauth_token.py) that opens a browser and extracts an oauth_token from the cookies.

Here lies the fundamental flaw: The token extracted by the manual script is a standard, short-lived OAuth2 Access Token, which typically expires after about an hour. It is not the long-lived Master Token.

The integration, however, stores both types of tokens under the same configuration key (CONF_OAUTH_TOKEN) and treats them identically.

Why the Manual Method is "Broken by Design"

When a user follows the manual setup path, the integration works perfectly for about an hour (maybe longer). Once the short-lived token expires, the entire authentication chain breaks because the integration has no mechanism (and technically, no possibility) to refresh this type of token. It cannot be "upgraded" to a long-lived Master Token.

This creates a frustrating user experience and is essentially a trap. It leads to the integration failing without a clear reason, forcing users to constantly re-authenticate manually.

The Regression That Masked the Issue

To make matters worse, a recent regression (introduced by myself) had also broken the reliable secrets.json method. A new, overly-defensive validation check was introduced in custom_components/googlefindmy/Auth/aas_token_retrieval.py (_disqualifies_oauth_for_exchange). This check incorrectly rejected the valid, long-lived Master Token because its aas_et/... prefix made it look like a short-lived token it was trying to avoid.

This effectively disabled the only stable authentication path, making it seem like the entire system was flawed. I have since patched this by removing the faulty check, restoring the secrets.json method to full functionality.

Conclusion: Remove the Manual OAuth Method

Given that the manual OAuth method is conceptually flawed and cannot provide the long-term stability our users need, I propose that we remove it entirely from the setup process.

Justification:

1. It's a User Trap: It provides a setup path that is guaranteed to fail, creating support overhead and user frustration.

2. It's Misleading: It asks for an "OAuth Token" when what the integration truly needs is a "Master Token," which can only be obtained via the secrets.json method.

3. Simplifies the Codebase: Removing it streamlines the config_flow.py and eliminates a source of persistent bugs.

4. Focuses on Reliability: By guiding all users to the secrets.json method, we ensure everyone has a stable, long-lasting authentication setup from the start.

This change makes the integration far more reliable and the setup process less confusing. The secrets.json method is the only one that has ever been capable of providing a stable, long-term solution.

I'm open to discussion and feedback on this.

Thanks,
Jens