For a GPT Action, OpenAI's Action authentication instructions place OAuth under Authentication in the GPT editor. The configuration asks for the client ID, client secret, authorization URL, token URL and scope. Keep the secret in its designated configuration, never in a troubleshooting prompt. A user's action invocation can then present a sign-in button. These instructions describe integration setup, not access guaranteed for every account.
For an MCP-based plugin, use OpenAI's plugin authentication guide. Copy the production redirect URI from the MCP server's management page. Its callback mode can be callback-ID-specific or stable, depending on the documented issuer-identification requirements and existing connection history. Do not copy a GPT Action callback into this registration. The plugin guide documents authorization-code flow with S256 PKCE; do not assume every other ChatGPT integration has identical parameters. These source routes were checked October 24, 2026.
Put the two redirect values beside the failure
This original fictional GPT Action case supplies three facts. The GPT ID is a placeholder:
R1 registered redirect:
https://chatgpt.com/aip/g-EXAMPLE/oauth/callback
R2 authorization request redirect_uri, decoded once:
https://chatgpt.com/aip/g-EXAMPLE/oauth/callback/
R3 observed provider page: redirect URI mismatch; no code received
R1 and R2 differ by a trailing slash. The supplied evidence supports checking the actual request and registration against the current Action instructions for the saved GPT. It does not establish what introduced the slash or that any configuration was changed successfully.
The OAuth security best current practice, RFC 9700, requires exact matching of registered redirect URIs, with an exception for port numbers in native-app localhost redirects. That exception does not apply to this HTTPS callback. Keep the precise approved URI instead of weakening redirect validation to accommodate the mismatch.
Identify the protocol stage before asking for a repair
| Observed stage | Useful evidence | Different question still unresolved |
|---|---|---|
| Authorization request rejected | Registered/requested redirect values; provider error | Whether a later token exchange would succeed |
| Callback received | Whether code or error arrived; transaction correlation result | Whether the code was exchanged successfully |
| Token endpoint rejected exchange | Redacted error, client type and request parameter names | Whether a resource API accepts the resulting token |
| Resource API denied request | Status, expected audience/scope and redacted token metadata | Whether the caller has access to that particular record |
Do not paste a full callback URL containing a code, a token response, client secret, code verifier, cookies or authorization headers. Replace sensitive values consistently while retaining the distinctions needed for diagnosis. For R1/R2, the scheme, host placeholder, path and trailing slash must remain distinguishable.
For the MCP flow documented above, PKCE uses a challenge and verifier. It does not make a mismatched redirect registration acceptable. Check state, issuer and other transaction requirements against the guide for the actual integration surface; a chat explanation does not establish that those protections work.
Copy a bounded troubleshooting prompt
Help interpret this OAuth integration failure without sending requests.
ChatGPT surface: [GPT ACTION / MCP PLUGIN / OTHER, IDENTIFY]
Provider and official surface-specific flow documentation: [LINKS]
Client type and flow: [ENTER; DO NOT ASSUME]
Library/version and environment: [ENTER]
Furthest observed successful stage: [ENTER]
Redacted registration/request comparison: [PASTE]
Exact sanitized error and where it appeared: [PASTE]
Checks already performed with actual results: [PASTE OR NONE]
Separate facts from hypotheses. Identify the first supported mismatch
and the smallest check that would distinguish its possible causes.
Preserve redirect validation, PKCE and transaction protections.
Ask for missing provider requirements instead of inventing them.
Do not request secrets, make account changes, exchange codes,
broaden scopes or claim the flow succeeded.
OpenAI's prompting documentation supports supplying the context and permitted action boundaries. The output should help the integration owner inspect a specific stage, rather than produce a fresh authentication implementation from an incomplete error message.
Retest the approved flow at its actual boundary
For the fixture, the next useful result is the request value after its construction and configuration sources have been checked. Record whether it matches the approved registration, then use the maintained application's normal test flow. This article performs no authorization request or token exchange.
After authentication works, object-level API access tests address whether the resulting identity may read a particular record. Successful OAuth authorization alone does not answer that application permission question.