Being able to reset auth

[alexey-yarmosh]

Steps to reproduce:

1. Auth to client to globalping.
2. Go to https://dash.globalping.io/tokens and revoke token of the associated app.
3. Measurements requests now return 401 Unauthorized, which is expected. But looks like there is no way to repeat the login, or at least reset to the no token state. So user is stuck in that unauthorized state.

[eyepokes]

Yeah, it seems the issue is in the mcp-remote client itself.
After the latest update, the maintainer managed to fix the refresh token flow, but in cases where both access_token and refresh_token become invalid, even if I delete the entries from KV to force a re-auth event, the data generated by the mcp-remote client on the user’s device doesn’t get saved — even if the client hasn’t been removed.

As with pretty much every OAuth-related issue, the only working recommendation so far is to delete the temporary data manually:

rm -rf ~/.mcp-auth  

[eyepokes]

@MartinKolarik Can you take a look for this one? Maybe I missing something

[MartinKolarik]

Which part exactly? The API correctly returns a 401 error when a token is revoked by the user. What you need to do in that case is forget the existing tokens, trigger a fresh user auth, and store the new tokens. I don't know how exactly to do that with mcp-remote but it seems similar to a regular refresh scenario, where you need to update and store both new tokens as well.

[eyepokes]

@MartinKolarik when I delete the existing tokens from the KV storage, it does trigger a reauthorization, but the mcp-remote client doesn't overwrite the outdated token data on the user's device, which results in an infinite loop of authorizations.
I think the best recommendation for now - until this option is implemented in the mcp-remote client is to instruct the user delete the data manually, like it described here

[MartinKolarik]

I think the best recommendation for now - until this option is implemented in the mcp-remote client is to instruct the user delete the data manually, like it described here

Ok, that's fine with me. Do you know if there's a related issue already open in mcp-remote?

[eyepokes]

@MartinKolarik I haven't seen anything specific for this exact scenario, but in general, I've come across 3-5 oauth related issues with comments suggesting manually deleting the contents of the ~/.mcp-auth folder

[MartinKolarik]

Then please open an issue for this problem and link it here so that it's at least documented and possibly fixed later.

[eyepokes]

@MartinKolarik here's the issue