@user369 Welcome to the forum!
Regarding the unwanted logout with the setting “never”, I would reference this other thread (beginning with post #4) . – And there is a related PR on GitHub, that you could also follow (“subscribe” to get notifications):
main ← platform/handle-401-refresh-token
opened 09:01PM - 15 Nov 25 UTC
## 🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-28303
fixes https… ://github.com/bitwarden/clients/issues/10718
## 📔 Objective
Attempt to refresh the access token if we receive a `401` response from an API request.
This matches the behavior on the mobile applications, and accounts for scenarios in which we've seen requests being delayed client-side (seemingly related to host sleep/hibernate states), only to proceed after the machine is active, at which point the now expired access token fails.
This change is meant to specifically address the case where:
1. We make an authenticated API request with an access token that is valid (not expired) at the time that our code calls `fetch()`.
2. For some reason, the request is not sent to the server until _after_ the access token has expired.
3. The Bitwarden API rejects the request with a `401` response because the token is not valid.
Specifically in this scenario, if we run the request building logic again, **the access token will now be detected as expired** and a `refresh_token` request will be issued to Identity. This refreshed access token can then be used to successfully send the request.
Besides renames and using `HttpStatusCode`s instead of magic strings for HTTP response statuses, the following substantial changes were made:
1. Added check for a `401` response on an authenticated request, and call `buildRequest()` again to refresh the token.
2. Changed the logout reasons to `SessionExpired` for an invalid refresh token (meaning that the refresh token (aka a "session" is no longer valid) and `InvalidAccessToken` for an API request that receives a `401` or `403` response. PR https://github.com/bitwarden/clients/pull/17608 builds on this by adding a log message on every logout with a reason.
3. Alphabetized the `LogoutReason` type and removed the `invalidGrant` reason, since it was no longer in use.
4. Separated out the response error handling into 2 separate methods for clarity. One handles responses from API requests, and one handles errors from requests to the token endpoint. Why don't we need to check for `401` or `403` on the token request failures? Because we're not calling an authenticated endpoint here, we're calling the token request endpoint, and that endpoint will respond with an [invalid grant](https://github.com/DuendeSoftware/products/blob/508e82a1f2e06ef9ff67d0453b387e8ae71692f3/identity-server/src/IdentityServer/Services/Default/DefaultRefreshTokenService.cs#L79-L80).
⚠️ This does **not** handle the following scenarios:
1. A `401` response is received because the wrong user's access token is sent on a request.
4. A `401` response is received due to network configuration issues.
In these case, the token isn't expired, and we'll send up the same (wrong) token again. At that point, we'll get a `401` again and log the user out as we did before. We'll have an extra request in this case, but it will fail both times.
## 📸 Screenshots
This demo demonstrates what happens in the scenario that this change covers, by doing the following:
1. Modifying the access token lifetime to be 10 seconds
2. Setting a breakpoint after the access token was acquired (when building the request) and **before** the ``fetch()` is executed.
3. Waiting at that breakpoint for more than 10 seconds. At this point, the token has expired.
4. Sending the request with the expired token.
5. Observing that the response is `401 - Unauthorized`
6. Letting the code execute to see that a subsequent refresh occurs, and the request then succeeds.
https://github.com/user-attachments/assets/a5250c87-29f0-4056-b63e-65001aebe675
## ⏰ Reminders before review
- Contributor guidelines followed
- All formatters and local linters executed and passed
- Written new unit and / or integration tests where applicable
- Protected functional changes with optionality (feature flags)
- Used internationalization (i18n) for all UI strings
- CI builds passed
- Communicated to DevOps any deployment requirements
- Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team
## 🦮 Reviewer guidelines
- 👍 (`:+1:`) or similar for great changes
- 📝 (`:memo:`) or ℹ️ (`:information_source:`) for notes or general info
- ❓ (`:question:`) for questions
- 🤔 (`:thinking:`) or 💭 (`:thought_balloon:`) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
- 🎨 (`:art:`) for suggestions / improvements
- ❌ (`:x:`) or ⚠️ (`:warning:`) for more significant problems or concerns needing attention
- 🌱 (`:seedling:`) or ♻️ (`:recycle:`) for future improvements or indications of technical debt
- ⛏ (`:pick:`) for minor or nitpick changes
When you get logged out, it is expected that also the biometric unlock method gets “resetted”.
You could consider reporting the unwanted logouts in the iOS section on GitHub: GitHub · Where software is built (I didn’t do an extensive search now, so please search for possible recent duplicates in the open and closed (!) issues first)
Also the “Why is it not accepting the master password unless I specifically open up the Bitwarden app and log in that way?” -part that @Llyander expressed should best be reported on GitHub. (–> GitHub is the place for bug reports)