OAuth for partners and agents

OAuth lets a partner app or public AI client connect on a customer’s behalf. If you are connecting your own unattended backend to your own account, an API key remains available as a server-to-server fallback.

Choose the client registration model

Public MCP and A2A clients can use a Client ID Metadata Document, with Dynamic Client Registration as a fallback. Confidential partner applications still need a pre-registered client ID, secret, redirect URLs, and allowed scopes. Delegated OAuth never issues account or admin.

Authorization flow

Infinite Audience uses the OAuth 2.0 authorization-code flow with PKCE (S256).

1. Send the customer to GET /v1/oauth/authorize with your registered client details and PKCE challenge.
2. The customer reviews the requested access. discovery is selected by default; creator and account-read require explicit opt-in. Some discovery operations run backend queries or update cached state, but do not purchase records.
3. Infinite Audience returns a short-lived authorization code to your registered redirect URL.
4. Exchange the code and PKCE verifier at POST /v1/oauth/token.
5. Use the access token for API requests and the refresh token to keep the connection active.

Authorization request

Parameter	Required	Purpose
client_id	Yes	A pre-registered partner ID or the HTTPS URL of a public Client ID Metadata Document
redirect_uri	Yes	Must exactly match an approved redirect URL. A portless HTTP loopback URL in public-client metadata may use the ephemeral port selected by the native client.
response_type	Yes	Use code
scope	No	Space-separated access requested from the customer
resource	Public clients: Yes	Exact resource URL for the token, such as https://mcp.infiniteaudience.ai/mcp. Confidential REST clients may omit it to use the API resource.
code_challenge	Yes	PKCE challenge derived from your verifier
code_challenge_method	Yes	Use S256
state	Recommended	Lets your app validate the returning request

For a discovery-only MCP connection, request scope=discovery explicitly and set resource=https://mcp.infiniteaudience.ai/mcp. Some MCP clients otherwise request every scope advertised in protected-resource metadata, including creator; the consent screen starts with only discovery selected, but the client should still request the access it actually needs. Validate the returned state and authorization-server iss before exchanging the code.

For MCP or A2A account-status tools, request account-read and use the corresponding resource URL. This allows usage, balance, and existing top-up status reads only. Approval requires an account holder; it cannot grant account administration, API-key creation, or credit purchases. An A2A token remains bound to https://a2a.infiniteaudience.ai/a2a and cannot be used directly on the MCP or REST resource.

Token exchange

This example is for a pre-registered confidential REST partner client:

curl -X POST https://api.infiniteaudience.ai/v1/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=$AUTH_CODE" \
  -d "redirect_uri=$REDIRECT_URI" \
  -d "client_id=$CLIENT_ID" \
  -d "client_secret=$CLIENT_SECRET" \
  -d "code_verifier=$CODE_VERIFIER"

For a public MCP client, omit client_secret and bind the code exchange to the same MCP resource used at authorization:

curl -X POST https://api.infiniteaudience.ai/v1/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=$AUTH_CODE" \
  -d "redirect_uri=$REDIRECT_URI" \
  -d "client_id=$CLIENT_ID" \
  -d "code_verifier=$CODE_VERIFIER" \
  -d "resource=https://mcp.infiniteaudience.ai/mcp"

Access tokens last 30 minutes. Refresh tokens last 90 days and can be exchanged at the same endpoint with grant_type=refresh_token; public clients must send the same client_id and resource during refresh. Authorization codes last 60 seconds and can be used once.

Use POST /v1/oauth/revoke when a connection is removed. Customers can also revoke a partner from their account settings, so treat a failed refresh as a cue to reconnect.

Verified identity for MCP enterprise domain checks

An MCP client may request openid email alongside its API scopes, for example scope=discovery openid email. These identity scopes work only with the MCP resource. They do not grant creator, account-read, or any other API capability. The customer sees the email disclosure on the consent screen. A client requesting email must also request openid.

An OIDC-enabled grant is tied to the person who approved it. Infinite Audience checks that person’s current organization membership and verified Firebase email before issuing or refreshing tokens and on later MCP calls. The email claim is disclosed to the client only when email was granted. Removing or suspending the person invalidates the connection. Existing OAuth grants without openid keep their normal organization-owned lifecycle.

The token response includes an RS256 id_token for OIDC-enabled MCP grants. The issuer publishes OIDC discovery and public signing keys. Call GET or POST /v1/oauth/userinfo with the MCP access token to read the current sub, and, when email was granted, email and email_verified: true. The UserInfo sub matches the ID token’s sub.

Device authorization for chat and terminal clients

A2A clients without a practical redirect callback can use the OAuth 2.0 Device Authorization Grant. The client displays a browser link and one-time code, then waits while the customer signs in and chooses scopes. The customer never pastes an API key or token into the conversation.

1. Register or identify the public client, then call POST /v1/oauth/device_authorization with client_id, the A2A resource, and the requested scope.
2. Show verification_uri_complete to the customer. If the client cannot open it, show verification_uri and user_code separately.
3. Poll POST /v1/oauth/token using grant_type=urn:ietf:params:oauth:grant-type:device_code, device_code, client_id, and the same resource.
4. Honor the returned interval. Keep waiting on authorization_pending; add five seconds after slow_down; stop on access_denied or expired_token.
5. Store the returned rotating refresh token in the client’s secure credential store.

A device-only client can use Dynamic Client Registration without a redirect URI:

{
  "client_name": "My A2A client",
  "grant_types": ["urn:ietf:params:oauth:grant-type:device_code", "refresh_token"],
  "response_types": [],
  "token_endpoint_auth_method": "none",
  "scope": "discovery creator"
}

curl -X POST https://api.infiniteaudience.ai/v1/oauth/device_authorization \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=$CLIENT_ID" \
  -d "resource=https://a2a.infiniteaudience.ai/a2a" \
  -d "scope=discovery creator"

discovery is selected by default in the browser. creator remains a separate, explicit customer choice. Device codes expire after 10 minutes and are bound to the requesting client and A2A resource.

Public AI clients

Public clients do not use a client secret. Infinite Audience supports:

• Client ID Metadata Documents for clients that publish their own HTTPS metadata URL.
• Dynamic Client Registration at POST /v1/oauth/register when metadata documents are unavailable.
• Resource-bound tokens for the MCP and A2A endpoints.
• Authorization code + PKCE for clients with browser callbacks.
• Device authorization for A2A-capable chat and terminal clients.

Public-client redirect URLs are still matched strictly. The only variable component is an ephemeral port on a portless HTTP loopback redirect declared by the client’s metadata, as required by native application OAuth flows.

If the browser reports ERR_BLOCKED_BY_CLIENT

A browser extension usually blocked the authorization URL before it reached Infinite Audience. Copy the URL into a private window or another browser, or allow api.infiniteaudience.ai (and dev-api.infiniteaudience.ai in development). Keep the originating AI client open so its temporary localhost callback can finish.