Skip to main content
IQRush remote MCP uses a browser authorization flow. Your client receives a bearer access token and uses it for requests on your behalf. You need an IQRush account with eligible organization access and permission to read the selected project. Signing in verifies your identity; it does not by itself grant integration access or access to every project.

​
Remote MCP authorization

The service advertises an authorization-code flow with PKCE using S256, the mcp:read scope, and refresh-token support. A compatible host discovers the authorization endpoints, registers its client when needed, opens the consent flow, and manages credentials. Use the authorization server metadata for your selected environment rather than guessing endpoint hosts. A metadata URL exposed by the service is the HTTP base plus /.well-known/oauth-authorization-server; its response supplies issuer, authorization_endpoint, token_endpoint, and registration_endpoint.

​
Building your own authorization flow

Before starting, choose the environment that contains your data and configure a callback URL in your application. Register that same URL as the redirect URI in the steps below. If you are connecting an assistant rather than writing a client, follow connection setup; the host manages this flow.
  1. Register your actual redirect URI using the discovered registration endpoint. Registration accepts redirect_uris and client_name; it returns a client_id. This does not grant access to project data.
  2. Generate a fresh PKCE verifier, its S256 challenge, and a random state value. Keep the verifier and state with the pending authorization request.
  3. Open the authorization endpoint with response_type=code, client_id, redirect_uri, scope=mcp:read, code_challenge, code_challenge_method=S256, and state.
  4. Let the user sign in and approve access in IQRush. Validate the returned state in your callback.
  5. Send a form-encoded token request with grant_type=authorization_code, the returned code, the same client_id and redirect_uri, and code_verifier.
  6. Store the returned tokens securely. Use expires_in to manage expiry. Refresh with grant_type=refresh_token, client_id, and the current refresh_token; save replacement credentials from the response.
Use an established OAuth client library for these steps. Do not copy a password, browser session token, or another client’s private token store into your integration.

​
Permissions follow the signed-in user

Project reads check the caller’s access. A project can return “not found” when it is unavailable to that caller. Do not use a different project’s ID to work around an access failure. Verify the account and workspace with list_projects. Account eligibility is also checked when sessions are authorized or refreshed. The service does not advertise a client-credentials grant for unattended service accounts in this edition. A desktop connector’s local authorization flow is separate from remote OAuth.

​
Renew or revoke access

After an expired or revoked credential, refresh if the client supports it or reconnect through IQRush sign-in. Repeated invalid_grant responses require a new authorization flow. Do not repeatedly replay an old refresh token. Use Settings → MCP → Connected clients → Disconnect to revoke a connection. Keep credentials out of code, URLs, public reports, and browser-delivered JavaScript.

​
Continue after authorization

For HTTP, keep the returned access token in IQRUSH_ACCESS_TOKEN and the matching HTTP base in IQRUSH_API_BASE, using secure application configuration. Make the project-list request to check the connection, then follow the report starter. For a custom MCP client, continue with protocol initialization and tool discovery, then select a project and run. The starter uses an existing access token. It does not implement this authorization flow or token renewal for you.