MCP OAuth authentication does not send the scopes `openid` and `profile`

API Bugs
1

When connecting an MCP Server using OAuth authentication, ChatGPT does not request the scopes openid and profile when obtaining the access token. This is an issue as the token being generating for example when using a server such as Auth0 is a valid token but it contains no claims and thus it does not identify the authenticated user.

ChatGPT should send those scopes if the server supports them. ChatGPT can discover whether the server supports those scopes when it visits the .well-known endpoints.

2 Likes
New MCP Connector does not follow MCP Authorization Spec
New MCP Connector does not follow MCP Authorization Spec
2

Blocked on this as well. Unfortunately I couldn’t find any easy workaround.

3

Hello!

While we look into this, I wonder if you can explicitly configure your connector (via Developer Mode) to send openid profile as the required scopes, or adjust your authorization server to include identity claims or issue an ID token even when no scope parameter is provided.

Let me know!

4

We are experiencing a similar issue. Could you please provide specific guidance on how to configure the connector in the developer mode, to send the scopes as you suggested?

5

if you can explicitly configure your connector (via Developer Mode) to send openid profile as the required scopes

The ChatGTP UI does not allow any configuration of scopes.

adjust your authorization server to include identity claims or issue an ID token even when no scope parameter is provided.

That it is not possible, the scopes need to be requested by ChatGPT, the user has to consent to those scopes and then the auth server generate the appropriate response

1 Like
6

We are also still dealing with this issue. Is there any update on this?

7

Hey everyone, We are looking into this issue with our team. We will get back with an update soon. Thank you!

2 Likes
8

Thanks for flagging this! By default, our client doesn’t request any scopes during the initial connection. We’ve recently made an update so that it now automatically discovers the required scopes from the www-authenticate header and requests them during the initial handshake instead.


This helps ensure the correct permissions are picked up automatically without manual intervention. For more details on how this works, you can refer to Section 4.2 (Protected Resource Metadata Discovery) in the specification here:

https://modelcontextprotocol.io/specification/draft/basic/authorization#protected-resource-metadata-discovery-requirements

Please let us know if you continue to see any issues after this change—we’re happy to help.

9

Hi, I just wanted to double check and ask if this change is also released for ChatGPT Enterprise instances? We did a few more tests, the DCR is now passed, but still it seems the scopes are not provided by ChatGPT to the AuthProvider (Azure in our case called through new version of FastMCP with DCR)

10

Hey Mostafa, yes these are applied for enterprise as well. Please refer to the guidance in the doc and it should be sorted for you. Thank you!

11

Hey there, we are also running into issues integrating ChatGPT with our hosted MCP server. ChatGPT appears to only want to request the offline, offline_access, and openid scopes even though our scopes_supported includes many more. We have also recently configured our WWW-Authenticate response header to include scope=”…” when we return a 403 Forbidden status code as per the MCP authorization spec

Is there something we’re missing?

12

Hey @David_S,


Please find the suggestion below. Hope it helps, if not I would suggest you to please open a support request with us at support@openai.com and do not forget to include this community thread link and your forum username for us to track it. Thank you!




Return a 401 (not 403) when auth is missing/invalid

  • ChatGPT’s discovery + scope guidance is driven off 401 Unauthorized responses. If you only send WWW-Authenticate on 403, the client may never treat it as authoritative.

On that 401, include a WWW-Authenticate: Bearer challenge with BOTH:

  • resource_metadata="https://…/.well-known/oauth-protected-resource/…"
  • scope="your:minimal required scopes"
  • Keep the scope list specific to the endpoint (least privilege).

Don’t rely on scopes_supported to influence what ChatGPT requests

  • Even if you advertise many scopes in metadata, ChatGPT will follow the scope="..." value from the WWW-Authenticate challenge for the current request.

Make sure your protected resource metadata endpoint is actually reachable

  • Serve the well-known URL (either root or path-based) so discovery works even if headers are missed.

Re-test and confirm behavior

  • Hit the MCP endpoint with no token → verify you get 401 + correct WWW-Authenticate header
  • Then run ChatGPT auth again → it should request the scopes you challenged.