MCP Server with Google OAuth & Analytics
bighadj22LABSCO SUMMARY
Solves a problem you only have once, but have permanently.
An internal MCP server behind corporate SSO is unreachable from most clients, and the usual workaround is pasting a token that expires by lunchtime. Doing the browser flow once and then refreshing ahead of expiry is the whole value here — after setup there is nothing to maintain. The diagnostics matter more than they look: when an enterprise OAuth flow fails it usually fails silently, and having status, token and clear as explicit commands is what turns that into a five-minute fix.
What it is
An authentication wrapper rather than a server with its own tools. It sits in front of mcp-remote, performs the OAuth implicit flow against Adobe IMS or Okta, and launches the underlying connection with an Authorization bearer header already attached — so a client that cannot do enterprise SSO can still reach a server that requires it.
What you get
- One command in your client config in place of a login flow: it builds the OAuth URL, opens the browser, catches the callback on a local HTTP server, extracts the tokens, stores them, and starts the connection with the header set
- Two providers behind one switch —
AUTH_PROVIDERselects Adobe or Okta, and only that provider's variables are required - Token lifecycle handled without you: storage in your home directory, expiry tracking, and automatic refresh controlled by
AUTO_REFRESHand aREFRESH_THRESHOLDin minutes - An optional JWT exchange for servers that want a JWT rather than the access token, selected with
AUTH_METHOD - CLI subcommands for when it misbehaves: authenticate, check token status, print the current token, and clear stored tokens
- A debug mode that reports configuration validation, token expiry and validity, each step of the OAuth flow, refresh timer scheduling, network requests and stack traces
- Multiple Adobe IMS environments through
ADOBE_IMS_ENV— production, stage or development — while Okta is targeted directly by domain
Requirements
A client ID from whichever identity provider fronts your server: ADOBE_CLIENT_ID for Adobe, or OKTA_CLIENT_ID together with OKTA_DOMAIN for Okta. The scope defaults sensibly per provider and can be overridden with ADOBE_SCOPE or OKTA_SCOPE. The redirect URI defaults to a localhost callback and is configurable through REDIRECT_URI. Node.js — the documented launch is npx mcp-remote-with-okta with the target MCP URL as its argument, or a global npm install. The package is mcp-remote-with-okta (1.3.0 in package.json). It runs on macOS, Windows and Linux.
Setup effort
One command plus credentials — npm install -g mcp-remote-with-okta, then supply credentials
USE CASES
01
Reaching an internal MCP server from a client that cannot do SSO
Put the wrapper in the client config with your provider and client ID, log in once in the browser, and connect normally from then on.
02
Not thinking about token expiry again
Leave auto-refresh on so the token is renewed ahead of its expiry rather than failing mid-session.
03
Testing against a non-production identity environment
Point the IMS environment at stage or development while you are wiring things up, then switch to production.
04
Diagnosing an authentication failure
Turn on debug mode and check token status, then clear the stored tokens and re-authenticate rather than guessing at the cause.
BEFORE YOU INSTALL
What to know first
Requires
- npx on PATH
- Node.js 18+
- OKTA_CLIENT_ID and OKTA_DOMAIN for Okta, or ADOBE_CLIENT_ID for Adobe IMS (AUTH_PROVIDER picks which)
INSTALLATION
Connect your client
Add the block to your client, or run the command directly.
Server setup
Configuration file
JSON
{
"mcpServers": {
"my-mcp-server": {
"command": "npx",
"args": [
"mcp-remote-with-okta",
"<YOUR_SERVER_URL>/mcp"
],
"env": {
"AUTH_PROVIDER": "okta",
"OKTA_CLIENT_ID": "<YOUR_OKTA_CLIENT_ID>",
"OKTA_DOMAIN": "<YOUR_OKTA_DOMAIN>.okta.com"
}
}
}
}npm
TERMINAL
npm install -g mcp-remote-with-okta
