Oauth flow persistence and usability

[jpambrun]

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.

1. toolhive start atlassian-remote
2. cat logs, and go through the flow
3. toolhive stop atlassian-remote
4. toolhive start atlassian-remote
5. [not authenticated]

Expected behavior

1. toolhive start atlassian-remote should present me with the oauth login url
2. 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.

[eleftherias]

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:

thv run atlassian-remote --remote-auth-client-id <ID> --remote-auth-client-secret <secret>

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.