[Bug]: CP OAuth DCR relay returns LiteLLM's own /callback as the client's redirect_uri, causing a self-redirect loop. Reopen for #33699

[ghevge]

Check for existing issues

• I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

The ticket #33699 currently marked as completed, is still not properly fixed.

Testing on litellm-database:v1.95.0-dev.1 and v1.95.0-dev.2 I can see that the behavior is still there.

The latest logs are below.

Just a side note: from what I can see, some of the changes pushed with the PR related to #33699 , are not visible in the latest code version.

Steps to Reproduce

1. Register an MCP server in LiteLLM pointed at an upstream that supports OAuth 2.1 with real Dynamic Client Registration and no admin-configured static client_id/client_secret, such as Atlassian's Rovo MCP server
2. Connect to that server from an OAuth 2.1 DCR-compliant MCP client that performs /register before /authorize and reuses the registration response's redirect_uris on /authorize (Open WebUI's native MCP External Tools with Auth: OAuth 2.1 (DCR) does this)
3. Complete the browser consent

Expected: the browser lands on the MCP client's own redirect endpoint with the final code/state, and the client completes its token exchange

Actual: the browser bounces to LiteLLM's own /callback a second time, which logs a decrypt error and returns "Authentication incomplete," the client never receives a valid code, and the subsequent tool call to the MCP server returns 401

Relevant log output

{"message": "10.80.24.15:55742 - "GET /health/liveliness HTTP/1.1" 200", "level": "INFO", "timestamp": "2026-07-24T15:50:28.755259", "component": "uvicorn.access", "logger": "h11_impl.py:482"}
{"message": "10.80.24.15:55754 - "GET /health/readiness HTTP/1.1" 200", "level": "INFO", "timestamp": "2026-07-24T15:50:28.766650", "component": "uvicorn.access", "logger": "h11_impl.py:482"}
{"message": "10.80.24.15:0 - "GET /atlassian/authorize?response_type=code&client_id=Lx03OjIJwyTXxL9Rm3T1MKUNOi8U0Z3f&redirect_uri=https:///callback&state=<STATE_1>&resource=https:///atlassian/mcp&code_challenge=rxmK41UdDelZpxpl-XZUuE4EWsQS0ujWPTO4y0JZh_o&code_challenge_method=S256
HTTP/1.1" 307", "level": "INFO", "timestamp": "2026-07-24T15:50:28.783341", "component": "uvicorn.access", "logger": "h11_impl.py:482"}
{"message": "10.80.24.15:0 - "GET
/atlassian/authorize?response_type=code&client_id=Lx03OjIJwyTXxL9Rm3T1MKUNOi8U0Z3f&redirect_uri=https%3A%2F%2F%2Fcallback&state=<STATE_2>&resource=https%3A%2F%2F%2Fatlassian%2Fmcp&code_challenge=2UbTSR1CeAiH8Kaz2m-BgABYv9KfGjqgWi8o4bv10mU&code_challenge_method=S256 HTTP/1.1" 307",
"level": "INFO", "timestamp": "2026-07-24T15:50:28.832094", "component": "uvicorn.access", "logger": "h11_impl.py:482"}
{"message": "10.80.24.15:0 - "GET /callback?state=<STATE_3>&code=<CODE_1> HTTP/1.1" 302", "level": "INFO", "timestamp": "2026-07-24T15:50:42.096265", "component": "uvicorn.access", "logger": "h11_impl.py:482"}
{"message": "10.80.24.15:0 - "GET /callback?code=<CODE_1>&state=<STATE_2> HTTP/1.1" 200", "level": "INFO", "timestamp": "2026-07-24T15:50:42.133701", "component": "uvicorn.access", "logger": "h11_impl.py:482"}
{"message": "Error decrypting value for key: oauth_state, Did your master_key/salt key change recently? \nError: Incorrect padding\nSet permanent salt key - https://docs.litellm.ai/docs/proxy/prod#5-set-litellm-salt-key", "level": "ERROR", "timestamp": "2026-07-24T15:50:42.132318", "component": "LiteLLM
Proxy", "logger": "encrypt_decrypt_utils.py:157", "stacktrace": "Traceback (most recent call last):\n File "/app/.venv/lib/python3.13/site-packages/litellm/proxy/common_utils/encrypt_decrypt_utils.py", line 137, in decrypt_value_helper\n decoded_b64 = base64.urlsafe_b64decode(value)\n File
"/usr/lib/python3.13/base64.py", line 134, in urlsafe_b64decode\n return b64decode(s)\n File "/usr/lib/python3.13/base64.py", line 88, in b64decode\n return binascii.a2b_base64(s, strict_mode=validate)\n ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^\nbinascii.Error: Incorrect
padding\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File "/app/.venv/lib/python3.13/site-packages/litellm/proxy/common_utils/encrypt_decrypt_utils.py", line 140, in decrypt_value_helper\n decoded_b64 = base64.b64decode(value)\n File
"/usr/lib/python3.13/base64.py", line 88, in b64decode\n return binascii.a2b_base64(s, strict_mode=validate)\n ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^\nbinascii.Error: Incorrect padding"}
ERROR:LiteLLM Proxy:Error decrypting value for key: oauth_state, Did your master_key/salt key change recently?
Error: Incorrect padding
Set permanent salt key - https://docs.litellm.ai/docs/proxy/prod#5-set-litellm-salt-key
Traceback (most recent call last):
File "/app/.venv/lib/python3.13/site-packages/litellm/proxy/common_utils/encrypt_decrypt_utils.py", line 137, in decrypt_value_helper
decoded_b64 = base64.urlsafe_b64decode(value)
File "/usr/lib/python3.13/base64.py", line 134, in urlsafe_b64decode
return b64decode(s)
File "/usr/lib/python3.13/base64.py", line 88, in b64decode
return binascii.a2b_base64(s, strict_mode=validate)
~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
binascii.Error: Incorrect padding

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/app/.venv/lib/python3.13/site-packages/litellm/proxy/common_utils/encrypt_decrypt_utils.py", line 140, in decrypt_value_helper
decoded_b64 = base64.b64decode(value)
File "/usr/lib/python3.13/base64.py", line 88, in b64decode
return binascii.a2b_base64(s, strict_mode=validate)
~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
binascii.Error: Incorrect padding
{"message": "10.80.24.15:55622 - "GET /health/readiness HTTP/1.1" 200", "level": "INFO", "timestamp": "2026-07-24T15:50:43.763807", "component": "uvicorn.access", "logger": "h11_impl.py:482"}
{"message": "10.42.0.242:47358 - "GET /metrics HTTP/1.1

What part of LiteLLM is this about?

No response

What LiteLLM version are you on ?

1.95.0-dev.1

Twitter / LinkedIn details

No response

[devin-ai-integration]

Reproduced and tracked down. The #33699 fix is in the code you are running; what is missing is the other half of the flow

The registration response does echo your client's own redirect_uris. The problem is that /authorize still accepted the proxy's own /callback as a client redirect_uri, because that URI is same-origin with the proxy so the redirect trust policy allowed it. Once a client sends it (which it will if it cached a registration from before the fix, or got one from the fallback registration arms that still echo the gateway callback when no usable redirect_uris are sent), the proxy seals it into the relay state as "the client's redirect", /callback decodes the state and redirects the authorization response to that redirect, which is /callback itself, and the second hit tries to decrypt your client's opaque state as a relay handle. That is the Error decrypting value for key: oauth_state / Incorrect padding line, the "Authentication incomplete" page, and the 401 on the following tool call

Fix in #34776: the redirect validator now rejects the gateway callback as a client redirect at /authorize, before the browser leaves for the upstream, and at the /callback sink for relay states minted earlier. Instead of the silent loop you get a 400 naming the cause

Two things you can do right now without waiting for a release:

1. clear the stored MCP registration your client holds for that server so it registers again and sends its own redirect_uri
2. set MCP_TRUSTED_REDIRECT_ORIGINS to your client's origin, e.g. MCP_TRUSTED_REDIRECT_ORIGINS=your-client-host.example.com

The second one is needed because your client runs on a different host than the proxy. Only same-origin, loopback and allowlisted origins are trusted at /authorize; a redirect origin that arrives through dynamic client registration is deliberately not auto-trusted, since registration is unauthenticated and trusting it would turn the proxy into an open redirect for authorization codes

On the double GET /<server>/authorize in your logs: both of those requests carry redirect_uri=https://<proxy>/callback, which is the same stale registration at work, so it should go away once the client re-registers