Found while smoke-testing EMA against live xaa.dev staging (during #1688). The flow works, but the Server Settings → OAuth Settings UI made it easy to enter the wrong credentials in the wrong place, costing several failed connect attempts.
EMA involves three distinct credential pairs, and the UI does not disambiguate them:
| Pair |
Source |
Belongs in |
| App client id/secret |
xaa.dev "Register New App" |
Client Settings (legs 1–2) |
| Resource Test Client id/secret |
xaa.dev resource registration |
Server Settings → OAuth Settings (leg 3) |
| — (IdP issuer) |
— |
Client Settings |
Problems
-
"Client ID" / "Client Secret" under the enterprise-managed toggle mean the resource authorization server credentials, not the IdP ones. The Checkbox description mentions this in passing ("OAuth fields below are resource authorization server credentials"), but the field labels themselves are unqualified, and they sit directly under a toggle whose label says "enterprise IdP" — which pulls the reader toward the IdP pair. Pasting the app pair here fails in leg 3 at the resource AS, with an error that does not point back at the field.
Suggestion: when enterpriseManaged is checked, relabel to e.g. "Resource AS Client ID" / "Resource AS Client Secret", or add a description naming the resource authorization server explicitly. core/auth/ema/emaFlow.ts already uses the precise language ("Test Client secret from xaa.dev resource registration").
-
The Scopes field does not state its delimiter. OAuth scope is space-delimited (RFC 6749); core/auth/scopes.ts splits on /\s+/ and joins with " ", and there is no comma handling. A comma-separated entry is sent as one junk token and rejected by the AS. Add a placeholder/description, e.g. mcp tools:read env:read / "Space-separated".
Notes
Reported by @cliffhall.
Found while smoke-testing EMA against live xaa.dev staging (during #1688). The flow works, but the Server Settings → OAuth Settings UI made it easy to enter the wrong credentials in the wrong place, costing several failed connect attempts.
EMA involves three distinct credential pairs, and the UI does not disambiguate them:
Problems
"Client ID" / "Client Secret" under the enterprise-managed toggle mean the resource authorization server credentials, not the IdP ones. The
Checkboxdescription mentions this in passing ("OAuth fields below are resource authorization server credentials"), but the field labels themselves are unqualified, and they sit directly under a toggle whose label says "enterprise IdP" — which pulls the reader toward the IdP pair. Pasting the app pair here fails in leg 3 at the resource AS, with an error that does not point back at the field.Suggestion: when
enterpriseManagedis checked, relabel to e.g. "Resource AS Client ID" / "Resource AS Client Secret", or add adescriptionnaming the resource authorization server explicitly.core/auth/ema/emaFlow.tsalready uses the precise language ("Test Client secret from xaa.dev resource registration").The Scopes field does not state its delimiter. OAuth scope is space-delimited (RFC 6749);
core/auth/scopes.tssplits on/\s+/and joins with" ", and there is no comma handling. A comma-separated entry is sent as one junk token and rejected by the AS. Add a placeholder/description, e.g.mcp tools:read env:read/ "Space-separated".Notes
clients/web/src/components/groups/ServerSettingsForm/ServerSettingsForm.tsx(+ its test/stories under the ≥90% per-file gate).Reported by @cliffhall.