Add expiration of unused refresh tokens

[mib1185]

Breaking change

Refresh tokens will be automatically deleted when unused. A refresh token is considered unused if it has not been used for a login within 90 days.
If you need a permanent token, then we recommend using Long-lived access tokens.

Proposed change

This adds an expiration period for unused refresh tokens of 90 days.
This only applies for "normal" (TOKEN_TYPE_NORMAL) tokens.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes Pile up of useless abandoned refresh tokens in user profile #103232
• This PR is related to issue: Add info about removing of unused tokens frontend#19479
• Link to documentation pull request: Add refresh token expiration home-assistant.io#30943

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hey there @home-assistant/core, mind taking a look at this pull request as it has been labeled with an integration (auth) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of auth can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign auth Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[mib1185]

rebased on latest dev to solve flaky tests

[mib1185]

meehhh ... one test failure is gone, a new one raises 🙄 🙈

[frenck]

New refresh tokens will be automatically deleted when unused. A refresh token is considered unused if it has not been used for a login within 90 days. This only applies to newly created refresh tokens (i.e. for new login sessions).

I discussed this yesterday with some and I want to change this to apply to existing refresh tokens too. Let me add a little context.

Initially, this was discussed on Discord, where the concern was raised: We don't know how existing refresh tokens are used: maybe in some applications... This resulted in the idea of only using it for new tokens.

However, there is no normal way to create these tokens manually. Any token you've created in the UI for these purposes (e.g., to hook up Node-RED or anything else) are long-lived access tokens (to which this logic already doesn't apply).

What is left is potentially a logged-in user, that hasn't used their application in 3 months or more. In the, assumingly, rare case that happens, a user will be logged out and can log in again.

The latter is the intended behavior of this change anyways.

../Frenck

[bdraco]

I agree. The majority of these tokens are never going to get cleaned up if we don't start the 3 month timer on all the old ones as well. If we wanted to be extra safe we could set the timer to be 6mo or 1yr for the old ones to give people time to sort things out if they only have access to HA one a year because they have the install in a remote location... but that seems like an extreme case.

[mib1185]

I'm also fine with let exiting tokens expire, too👍
We can also set the initial expiration to 180 or 360 days, but they would shorten to 90 days as soon as these token were used. if we want keep these increased expiration period for "old" tokens, we need to do some extra checks based on the version property of the RefreshToken, but i'm not sure if this it worth to do 🤔
I'm happy to follow any advice on this and adjust the PR accordingly 😊

[balloob]

Let's do 90 days for all.

[bdraco]

I'll test this in a bit

[bdraco]

I have one token that isn't getting an expire time... digging in

[bdraco]

nevermind, token type is system.

This is expeted

[bdraco]

checking Profiler: Log event loop scheduled

[bdraco]

I changed the expire time to 1 minute to test locally and verified I got logged out.

Now checking to make sure expire_at is being extended ok

[bdraco]

Running a 40 minute test now

[bdraco]

Testing looks great.

No ill effects observed on production either

[bdraco]

Thanks @mib1185