OAuth token refresh hits the wrong endpoint when the auth server lives under a path

Open

#3,240 opened on Aug 3, 2026 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 4/5
Estimated time: 3-5 days
Newbie friendliness: 48/100

Issue type: Bug
Clarity: Clearly specified
Activity status: Quiet
Tech stack: python
Domain: api, authentication

Research direction

Start by tracing async_auth_flow and its eager refresh path into _refresh_token, then compare the fallback behavior in _get_token_endpoint, _perform_authorization_code_grant, and DCR. Reproduce the cached-expired-token scenario against an authorization server whose metadata endpoints include a path. Done means refresh uses the discovered token endpoint and does not clear valid tokens or fall back to interactive authentication.

Written by the indexing model from the issue text.

Description

P1 v1 v2

Ran into this with a hosted MCP server whose authorization server isn't at the origin root — token endpoint is https://host/oauth2/api/v1/token, not https://host/token.

If a client starts up with a cached-but-expired access token (+ refresh token) and hasn't done discovery yet, async_auth_flow refreshes at the very top — before any 401/metadata discovery. So oauth_metadata is None and _refresh_token uses the fallback urljoin(get_authorization_base_url(server_url), "/token"), i.e. just {scheme}://{netloc}/token. That 404s, _handle_refresh_response clears the tokens, and the flow drops to full interactive auth — which a headless/gateway client can't do. So the server silently disconnects every time the access token expires (mine are 5 min, so… constantly).

Same path-stripping fallback is in _get_token_endpoint, _perform_authorization_code_grant (/authorize) and DCR (/register) — refresh is just the one that bites silently.

Repro (roughly):

MCP server whose AS metadata puts token_endpoint under a path, not {origin}/token
log in normally so tokens get cached
let the access token expire (or clear the expiry), reconnect with a fresh provider
watch the refresh POST go to https://host/token → 404 → "Token refresh failed" → tokens cleared → it tries to open a browser

Fix looks like: discover metadata before the eager refresh (or stop dropping the issuer path in the fallback). Happy to PR — have a branch that pulls the PRM/ASM discovery out of the 401 branch and runs it before the refresh.

(used some AI help digging into this)

Dominant language: Python
Stars: 24.3k
Forks: 4k
Avg merge: 1d 11h
Merged PRs (30d): 30

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

[essnmx] Fix typo in NXLauetof application definition Open

essnmx good first issue

Difficulty 1/5 Under an hour Newbie friendliness 95/100

scipp/ess#760 · Opened Sep 23, 2026
[Feature] 奇物选择添加优先级 Open

Difficulty 2/5 1-3 hours Newbie friendliness 65/100

syfoud/Simulated_Scepter#174 · Opened Sep 23, 2026
garak adapter grades a NaN detector score as PASS Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

Giskard-AI/giskard-oss#2840 · 1 comment · Opened Sep 23, 2026
A claim comment carrying the issue number is silently declined while the workflow reports success Open

area: repo bug perceived difficulty: 2

Difficulty 2/5 1-3 hours Newbie friendliness 70/100

Nitjsefnie-Harness-Commons/daedalus#926 · Opened Sep 23, 2026
`IOCExtractor` always fails: `ioc_analyzer.build()` takes 1 argument but the agent dispatcher passes 2 Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

yeti-platform/yeti#1380 · Opened Sep 23, 2026

More Python issues