InfraScout Is Now an OAuth Client for Remote MCP Servers

July 23, 2026 · InfraScout Team

Registering an MCP server used to mean finding a long-lived token somewhere, pasting it into a header field, and hoping nobody rotated it without telling you. That works for servers that issue API keys. It works badly for the growing number that speak OAuth, where the honest answer to "what token do I paste" is that you were never supposed to be handling one.

InfraScout can now be a proper OAuth client. Pick OAuth as the authentication method, click Connect, approve the access in the provider's own consent screen, and the card says Connected. No token passes through your hands.

What the flow actually does

The consent screen opens in a popup, on the provider's own domain, showing you what access is being requested. You approve it there — which means the credential you type is the provider's, never InfraScout's, and InfraScout never sees it.

What comes back is an access token scoped to that grant, stored the way every other secret in InfraScout is stored: encrypted, never rendered back as a value, never written to a log. From then on the tokens are InfraScout's problem rather than yours. They refresh in the background before they expire, so a connection you set up once keeps working without anyone revisiting it.

Where the provider supports dynamic client registration, InfraScout registers itself and there is nothing to configure. Where it does not — plenty of enterprise gateways still expect a client to be pre-registered by hand — an Advanced panel takes the client credentials your identity team issues.

The two things the card tells you

A background refresh loop is only trustworthy if it admits when it has stopped working. Two states surface on the server card rather than showing up as a failed tool call in somebody's chat.

Reconnection needed. If a refresh fails in a way that cannot be retried — consent revoked at the provider, a grant deleted, an account disabled — the card asks you to reconnect. That is a far better failure than tool calls returning an opaque authorization error while everyone assumes the server is down.

The refresh grant's own expiry. This is the subtle one. Most providers issue refresh tokens that do not expire, so a working connection stays working indefinitely. Microsoft Entra is a notable exception: it states an expiry for the refresh grant itself, and when that date passes, no amount of automatic refreshing helps. InfraScout now captures that expiry where a provider publishes one, shows it on the card as a Refresh expires line, and warns you when it is within a week.

Without that, an Entra-backed connection would work perfectly for months and then stop, with nothing anywhere having flagged that the clock was running. A week's notice is enough to reconnect at a time you choose.

Including servers you cannot reach

OAuth composes with agent-hosted MCP servers, which is where it gets genuinely useful. A server on an internal network is often fronted by an identity provider on that same internal network — neither of which InfraScout can reach directly.

In that case the OAuth exchange is routed through the hosting agent, alongside the tool calls. The token is obtained from inside your network, refreshed from inside your network, and used from inside your network. The pattern is the same one the tool calls follow: the agent is already in the right place, so the work happens there.

On the security of the flow

An OAuth client is a piece of security machinery, so a few of the properties are worth stating plainly rather than leaving implied.

Every outbound leg InfraScout dials is validated against the same protections that guard the rest of its outbound traffic, so a registration cannot be used to make InfraScout fetch something it should not. The authorization request carries a single-use, high-entropy state value and a PKCE challenge, and a pending flow expires after ten minutes. The provider's authorization endpoint has to be HTTPS before a browser is ever redirected to it. The callback page is fixed HTML with no redirect parameter, so it cannot be turned into an open redirect. Token material lives only in the secrets layer — not in the database, not in logs, not in any JSON the portal renders.

Two more properties came out of adversarial review before this shipped, and they are the kind that only surface when someone actively tries to break the flow. Repointing a server's URL while an OAuth flow is pending used to be able to land a token issued for the old host onto the new one; the flow now re-verifies that the registration still matches before it exchanges the code, and aborts if it does not. And the coordination that ensures only one replica refreshes a token at a time now allows enough time for the slowest legitimate refresh — including one routed through an agent — because a refresh token that gets submitted twice is a refresh token the provider revokes.

Try it

Open AI Integrations → MCP Servers, add or edit a remote server, choose OAuth, and click Connect. If you are connecting something Entra-backed, note the Refresh expires line that appears on the card afterward — that date is worth knowing about before it matters.

Full details in MCP Servers. Questions? info@infrascout.cloud.