Repository navigation
Oauth flow persistence and usability #3331
Description
Bug description
I am trying this for the first time; I trying to connect to atlassian-remote just to get started.
I have the linux keyctl setup and can add/list/get secrets.
stating
> toolhive start atlassian-remote
4:49PM INFO Loaded configuration from state for atlassian-remote
4:49PM INFO Starting tooling server atlassian-remote...
4:49PM INFO Logging to: /home/jpambrun/.local/share/toolhive/logs/atlassian-remote.log
4:49PM INFO MCP server is running in the background (PID: 4120044)
4:49PM INFO Use 'thv stop atlassian-remote' to stop the server
but it doesn't work, the logs indicate the issue
4:52PM INFO Starting OAuth authentication flow for issuer: https://cf.mcp.atlassian.com
4:52PM INFO Successfully registered OAuth client dynamically - client_id: nG58...
4:52PM INFO Using OAuth endpoints - authorize_url: https://mcp.atlassian.com/v1/authorize, token_url: https://cf.mcp.atlassian.com/v1/token
4:52PM INFO Opening browser to: https://mcp.atlassian.com/v1/authorize?client_id=nG58rBQ_SHP1FKbf&code_challenge=Ryo...&code_challenge_method=S256&redirect_uri=http%3A%2F%2Flocalhost%3A8666%2Fcallback&response_type=code&scope=openid+profile&state=3ELw..
I only have 30s to start, cat the logs and go through the flow. This isn't amazing, but it works.
However, I expected to see some new secrets with toolhive secret list, but didn't see any. Restarting the Atlassian mcp I am presented with the same logs requesting another oauth flow.
Am I missing something?
Steps to reproduce
Provide steps or commands needed to reproduce the issue.
- toolhive start atlassian-remote
- cat logs, and go through the flow
- toolhive stop atlassian-remote
- toolhive start atlassian-remote
- [not authenticated]
Expected behavior
- toolhive start atlassian-remote should present me with the oauth login url
- I expect some sort of secret to be persisted and being able to restart the mcp server without having to go through the flow again.
Actual behavior
No persistence
Environment (if relevant)
- OS/version: linux under WSL
- ToolHive version: v0.7.1 (73d4f26)
Additional context
Any additional information or logs you think might help.
Activity
eleftherias commentedon Jan 19, 2026
Hey @jpambrun, it looks like you're having 2 issues:
1. The OAuth flow is not starting automatically, so you need to find the login URL in the logs
By default ToolHive will try to open your browser to initiate the OAuth flow. It's likely your environment is blocking this behaviour. ToolHive should detect this and print a log message with the login URL, but it's not doing that, which is a bug. I will look into why it's not printing the login URL.
2. The OAuth credentials aren't persisted between restarts
In the case of the atlassian-remote server ToolHive is using dynamic client registration to create the client ID and secret. These are not persisted in the secret store and are regenerated on every new run. It's on our TODO list to persist the dynamic credentials.
If you had static credentials, like this:
then they would be persisted in the secret store and you would see them when running
thv secret list.However, in both cases the login flow is re-initiated to get a fresh token when the server restarts. ToolHive doesn't persist the tokens between server restarts, only the client ID and secret. If this is something that's causing friction, we can definitely revisit it.
feat(auth): persist OAuth tokens across workload restarts
feat(auth): persist OAuth tokens across workload restarts
feat(auth): persist OAuth tokens across workload restarts
feat(auth): persist OAuth tokens across workload restarts
feat(auth): persist OAuth tokens across workload restarts (#3382)
feat(auth): persist OAuth tokens across workload restarts (#3382)
eleftherias commentedon Jan 26, 2026
We are tracking these issues in #3377 and #3335.
After some investigation into why the login URL is not shown in the logs, it's proven to be a non-trivial fix. We're still continuing to look into it.
The other issue about persisting the DCR credentials is in progress.