[Bug]: Microsoft 365: Backend POST /api/mcp/oauth/login failed (500): {"success":false,"error":"Internal server error.","code":"INTERNAL_ERROR"}

[khoapnt-vng]

Module

Agent Detection & Connection

Platform

macOS (Apple Silicon)

AionUi Version

v2.1.39

Bug Description

As adding the MCP tools into the AionUI, i am facing a problem that i cannot login or authentication? what it could be about? I configure something wrong?

Steps to Reproduce

1. Go to tools
2. copy the url mcp in claude connectors such as microsoft 365 and add this url MCP via chat but cannot login
3. [Bug]: Microsoft 365: Backend POST /api/mcp/oauth/login failed (500): {"success":false,"error":"Internal server error.","code":"INTERNAL_ERROR"}

Expected Behavior

it should be pop up to login SSO and approve use the MCP tools

Actual Behavior

pop up: [Bug]: Microsoft 365: Backend POST /api/mcp/oauth/login failed (500): {"success":false,"error":"Internal server error.","code":"INTERNAL_ERROR"}

Additional Context

No response

[omarmciver]

The root cause of this is in the AionCore backend, not AionUi — which is why it presents as an opaque INTERNAL_ERROR with no browser popup. I've opened a fix: iOfficeAI/AionCore#988.

Reproduced with a second server (monday.com), so this affects any MCP server requiring OAuth, not just Microsoft 365:

{ "mcpServers": { "monday": { "type": "http", "url": "https://mcp.monday.com/sse" } } }

Why it fails

Two separate defects in crates/aionui-mcp/src/oauth_service.rs.

1. Discovery probes the wrong well-known URLs. The code appended .well-known/... to the full server URL, so https://mcp.monday.com/sse was probed at https://mcp.monday.com/sse/.well-known/oauth-authorization-server. RFC 8414 puts the well-known segment between the origin and the resource path instead. Probing exactly what the old code requested:

URL	Status
https://mcp.monday.com/sse/.well-known/oauth-authorization-server	401
https://mcp.monday.com/sse/.well-known/openid-configuration	401
https://mcp.monday.com/.well-known/oauth-authorization-server	200
https://mcp.monday.com/.well-known/oauth-protected-resource/sse	200

Both probes fail → the error maps to ApiError::Internal → HTTP 500, and the public message is scrubbed to "Internal server error." That is the popup you're seeing: the real reason never reaches the UI.

2. The OAuth client ID is hardcoded to "aionui". Servers requiring dynamic client registration (RFC 7591) reject it, so login could not complete even after discovery was fixed. monday advertises a registration_endpoint, and registering against it returns a working client ID.

The fix

The PR implements the spec discovery chain (RFC 9728 → RFC 8414/OIDC, resolved against the origin), adds RFC 7591 dynamic client registration, and stops mapping discovery failures to a 500 so the actual reason is surfaced instead of INTERNAL_ERROR.

Verified against the live monday.com server: discovery now resolves the endpoints, while the two URLs the old code probed still return 401.

To answer the original question — you did not configure anything wrong. This is a backend bug.