Longer oauth expiry date

[shahonseven]

Please allow for longer oauth expiry date.

[jubnl]

wdym ? what issue do you face ?

[shahonseven]

my oauth session expires daily so its really annoying when my ai agent opened few tabs trying to refresh the token that I have to close manually. I prefer api tokens as it dont expire.

[jubnl]

You can just use the MCP. OAuth 2.1 is supported, even with DCR, and there's a refresh token

• https://github.com/mauriceboe/TREK/wiki/MCP-Overview
• https://github.com/mauriceboe/TREK/wiki/MCP-Setup
• https://github.com/mauriceboe/TREK/wiki/MCP-Scopes
• https://github.com/mauriceboe/TREK/wiki/MCP-Tools-and-Resources
• https://github.com/mauriceboe/TREK/wiki/MCP-Addon-Tools
• https://github.com/mauriceboe/TREK/wiki/MCP-Prompts

When using the MCP, I don't have to log in every time, even if quite some time passes.

The web app is made for human usage

[shahonseven]

I am using mcp, but everyday it opens 5-10 browser windows trying to reauthenticate itself.

[jubnl]

Issue is valid, diagnosis is wrong though. There's a race condition happening there. From your screenshot, an oauth token replay has been detected, meaning the refresh token was used, it nuked all previous sessions server side and your other sessions try to refresh the token with the old token that has already been deleted.

I'll make a patch in the next few days.

[mauriceboe]

Fixed in 4.0.0 — and @jubnl's read of it was right, it was the race, not the lifetime.

For the record on the lifetime, since that was the original ask: access tokens already last an hour and refresh tokens roll for thirty days. Nothing there was expiring daily.

What was happening is that refresh rotation is a race by construction. Several MCP sessions share one refresh token, two of them post it within the same second, and the loser was read as a replayed token: the whole chain got revoked, sessions were torn down, and you got a login window. Repeat daily.

A revoked refresh token now only counts as a replay once it is more than 30 seconds past the rotation that revoked it, and only when that rotation left a live successor behind. Inside the window the second caller simply gets its own token pair. Theft is still caught — a stolen token used later, or after the chain was already killed, is refused exactly as before — and an explicit logout is not re-opened by the window either. This is the leeway RFC 9700 §4.14.2 asks for.

If you want to avoid refresh tokens entirely for an unattended agent, machine clients (client credentials) are still the better fit: no refresh token, no rotation at all.