Authentication expiring after 30 min - 5 hrs (Nest and Google Accounts)

[Happyllama25]

Describe the bug When authenticating a Nest account with the access_token, it stops working after 30 minutes with Auth failed: access token specified in Homebridge configuration rejected I then did the Google account authentication (with issueToken and cookies) and it also expired after 5 hours.

I did not log out, I closed the browser tab, and the Nest home.nest.com/session shows expires_in: "Thu, 05-Oct-2023 07:36:22 GMT", but after 30 minutes it asks to login again.

To Reproduce Steps to reproduce the behavior:

1. Authenticate with either Nest or Google cookies
2. 30 minutes for Nest and 5 hours for Google cookies

[wrsjr04]

I used the api key and all seems to be working. Been using it for a week now.

[adriancable]

@wrsjr04 - like @NathObeaN's "workaround" this is a placebo. Cookie expiry times vary hugely and having things work for a day one time, and two months the next, is not unusual. API keys do not impact cookie expiry time.

[wrsjr04]

@wrsjr04 - like @NathObeaN's "workaround" this is a placebo. Cookie expiry times vary hugely and having things work for a day one time, and two months the next, is not unusual. API keys do not impact cookie expiry time.

So google's cookies vary in time between each one? To where you can eventually get one that expires after x amount of time?

[adriancable]

@wrsjr04 - cookies should have a long expiry time so that you don't constantly need to log back in to web services, which is a pain. On the other hand, cookies should have a short expiry time so you don't have long-running active login credentials hanging around which could be harvested by malware, used by other people using the same computer/device, etc. since this presents a security risk. Obviously these two aims pull in opposite directions, so Google has an algorithm which decides how long cookies should be valid for. The inputs to the algorithm are not public, to prevent manipulation, but it's known for example that the IP address that you are making API requests from makes a difference, presumably because Google applies some heuristic to how 'public' the machine behind it may be. For example, logins to lots of different accounts from the same IP in a short space of time will lead to short cookie expiry times. But there are almost certainly many many many other factors which we don't know.

The cookie expiration logic is implemented as part of Google's user authentication layer, which happens before anything else, including figuring out what service the call is being made to, interpreting the body of the call, parsing other headers like API keys etc. So fiddling with any of these things cannot impact cookie lifetime.

When receiving a cookie, you don't know in advance how long it will be valid for. The cookie does have an expiration date, but this is always far in the future, and not meaningful since Google can (and does) expire cookies at any time before this date.

In general I applaud experimentation but please know that in this case, it is like sacrificing goats to make it rain. If you sacrifice enough goats, it will eventually rain, because if you wait long enough, it rains. The sacrifice has nothing to do with it.

[adriancable]

Adding a note: if you are looking for a productive direction on how to solve this, forget about cookies. The right approach is to figure out how to generate refresh tokens in the browser, like the OOB flow used to be able to do, before Google disabled it. This is almost certainly possible using puppeteer-plugin-extra-stealth or something similar to log into Google from the browser using the app-based OAuth2 flow and then intercepting the response at the end which contains the refresh token, before the OAuth2 flow redirects to a custom URI which a browser can't handle. Unfortunately, I don't have the free time right now to spend digging into this.

[alexwohlbruck]

I suppose it's possible to simulate a web login using puppeteer like you mentioned or some kind of headless selenium instance. It would require that you hand over login access to your google account in some way (app passwords? TOTP key?), but as long as we keep things local and secure this should be okay. I might like to take on this project if one of the project maintainers can kick me off with the high level overview of how the auth process works. @adriancable @chrisjshull

[tablatronix]

Could nodered do this?

[alexwohlbruck]

Could nodered do this?

Possibly, but it would be better to achieve a solution without any dependencies

[wrsjr04]

As Alex said is there any with documentation available would love to help get the issue fixed and find a new auth method that could be used to allow us to interact with nest as the smart device management api doesn't allow all the features.

Edit: Spelling

[wrsjr04]

Also can we add something in the readme.md file stating this is a know issue and linking this thread?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lNOFXl]

yup, updated my google password and now I'm stuck in this mess as well. Now I'm no computer professional by any means, wish i could help fix this but... I'm just a mechanic that's very good at following instructions. I've setup google assistant SDK to at least lock my locks from homeassistant automatically... i guess on the bright side... this makes my setup safer as it can only lock haha

[jballer]

I ended up buying a Starling hub and hadn't thought about this issue since. Wondering what they do differently? I suppose they grab an API key with the iPhone app and copy it to the hub programmatically?

[lNOFXl]

Yeah, thought about it but I don't want another hub to power with the battery backup. My computer is already running