Cel mai util detaliu din acest articol nu este teoria OAuth. Este faptul foarte concret că VS Code trebuie preregistrat ca authorized client pentru aplicația ta MCP în Entra, folosind client ID aebc6443-996d-45c2-90f0-388ff96faa56, altfel fluxul de autentificare se rupe repede.
Asta contează pentru că multe discuții despre autentificarea MCP încă se blochează în jurul soluției greșite: unii scot parametrul resource doar ca să nu se mai plângă Entra. Poate pornește un demo, dar pentru enterprise este direcția greșită. Sursa arată bine de ce. MCP se bazează pe resource indicators, iar Entra validează acum mai strict, cu erori precum AADSTS9010010 când resource și scopes nu se potrivesc.
Ce ne spune de fapt articolul
Asta este mai puțin o poveste despre Copilot și mai mult un reality check despre autentificare enterprise pentru custom MCP servers. Dacă serverul tău MCP trebuie să funcționeze cu VS Code, clienți de tip Copilot sau tooling intern pentru agenți, preregistration nu este infrastructură opțională. Este parte din designul produsului.
Sursa mai face și o corecție corectă legată de Dynamic Client Registration și client metadata documents. În tool-uri orientate spre dezvoltatori, ele par comode. În medii enterprise, însă, măresc suprafața de atac într-un mod pe care mulți administratori nu îl vor accepta.
Aici poziția Entra mi se pare rezonabilă. Mai enervantă, da. Dar și mai sinceră față de modul în care organizațiile controlează încrederea dintre aplicații.
Configurația concretă care merită preluată
Două fragmente din sursă sunt partea importantă.
Primul: serverul expune OAuth protected resource metadata și cere autentificare pe endpoint-ul MCP:
var builder = WebApplication.CreateBuilder(args);
builder.Services
.AddMcp(options =>
{
options.ResourceMetadata = new ProtectedResourceMetadata
{
Resource = resourceUri,
AuthorizationServers = { entraAuthority },
ScopesSupported = { requiredScope },
};
});
app.MapGet("/health", () => Results.Ok(new { status = "healthy" }))
.AllowAnonymous();
app.MapMcp("/mcp")
.RequireAuthorization();
Al doilea: app registration-ul MCP trebuie aliniat cu valorile resource și scope pe care clientul le va cere:
{
"Mcp": {
"ServerUrl": "http://localhost:7071",
"ResourceUri": "http://localhost:7071/mcp",
"RequiredScope": "api://eba71e23-a335-4584-a90d-69d732c8a7ff/access_as_user"
},
"Entra": {
"Authority": "https://login.microsoftonline.com/organizations/v2.0",
"Audience": "eba71e23-a335-4584-a90d-69d732c8a7ff"
}
}
Un alt detaliu practic pe care nu l-aș sări: setează api.requestedAccessTokenVersion la 2 în manifestul aplicației.
La ce aș fi atent
Pentru majoritatea echipelor, impactul este limitat, dar important:
- Dacă ai construit un proof of concept MCP cu presupuneri relaxate despre auth, verifică-l acum cu Entra.
- Dacă stack-ul clientului tău elimină sau rescrie parametri OAuth, așteaptă-te la comportament inconsistent.
- Dacă vrei să funcționeze în tenants reale, proiectează de la început pentru app registration ownership, consent și least privilege.
Ultimul punct este cel strategic. Odată ce serverele MCP încep să stea în spatele Microsoft Copilot și AI agents, deciziile de autentificare devin decizii de platformă. Dacă modelul tău depinde de hack-uri în SDK sau de ocolirea validărilor Entra, construiești pe nisip.
Verdictul meu: este un articol bun și practic pentru că împinge oamenii departe de workaround-ul simplu, dar greșit. Dacă legi MCP enterprise de VS Code sau de automatizări interne, tratează preregistration și alinierea scopes ca cerințe de bază. Este răspunsul plictisitor, dar în AI workflow automation, autentificarea plictisitoare este de obicei autentificarea corectă.
