Pravděpodobně nepotřebujete ruční ověřování (a ani jste o tom nevěděli)

Proč většina agentů v Copilot Studio nepotřebuje ruční ověřování a jaké mýty Vám brání v jednodušší konfiguraci.

Pravděpodobně nepotřebujete ruční ověřování (a ani jste o tom nevěděli)

Pojďme se na chvíli pobavit o manual authentication v Copilot Studio. Nejspíš jste ho už někdy nastavovali. Možná ho nastavujete právě teď. Jenže je tu jedna věc: pravděpodobně ho vůbec nepotřebujete.

„Počkat, cože?“ slyším Vás. „Vždyť už jsem na straně 23 dokumentace a jsem v půlce druhé app registration!“

Ano, autentizaci potřebujete. Ale nejspíš nepotřebujete manual authentication. Dejte mi chvilku.

Co je vlastně manual authentication?

Manual authentication v Copilot Studio Vám umožní napojit se na libovolného OAuth 2.0 providera — Entra ID, Google, Facebook, nebo třeba ten vlastní identity provider, který si Vaše organizace postavila v roce 2012 a dodnes ho odmítá vypnout. Je to výkonné a flexibilní.

Jenže s touhle flexibilitou přichází… poměrně dost konfigurační práce.

Když manual authentication zapnete, typicky musíte:

  1. Vytvořit dvě samostatné app registration (podle best practices)
  2. Zorientovat se v méně intuitivních nastaveních typu Token Exchange URL (a upřímně, ani to není tak úplně URL…)
  3. Smířit se s tím, že tohle celé není solution-aware pro ALM — tedy že někdo s oprávněními v produkci bude muset ručně aktualizovat detaily app registration.

Lepší cesta: Authenticate with Microsoft

Copilot Studio má vestavěnou možnost ověřování „Authenticate with Microsoft“, která je navržená přímo pro scénáře s Entra ID. A je to o dost jednodušší.

Proč je to lepší

Bez App Registration pro Teams, M365 Copilot a SharePoint: Pokud používáte jako kanály Teams, Microsoft 365 Copilot nebo SharePoint, autentizace funguje „sama od sebe“ a bez jakékoliv konfigurace
Jednodušší App Registration pro web: Stačí jedna App Registration s minimem nastavení (viz níže)
Tenant Graph Grounding: Umožní kvalitnější odpovědi ukotvené v SharePointu a Graph Connectors

Proč tedy firmy pořád používají manual auth pro interní scénáře?

Když je „Authenticate with Microsoft“ pro interní agenty s Entra ID výrazně jednodušší, proč se v enterprise prostředí pořád tak často setkáte s manual authentication?

Dobrá otázka. Ve výsledku za tím stojí dva rozšířené mýty, kvůli kterým lidé tu jednodušší cestu vůbec neobjeví. Pojďme je rozebrat.

Mýtus #1: „Pro WebChat potřebuji manual authentication“

Tohle je nejspíš největší mýtus, který lidi zbytečně odrazuje od jednoduššího řešení.

Mýtus: „Když chci svého agenta vložit na web, musím použít manual authentication.“

Realita: Kdepak. Pro web chat můžete úplně v pohodě použít „Authenticate with Microsoft“.

Microsoft k tomu nabízí oficiální ukázky, kde je přesně vidět, jak to nastavit:

Obě ukázky demonstrují:

  • Přihlášení uživatele přes Entra ID pomocí pop-up okna
  • Výměnu tokenu mezi Vaší webovou aplikací a Copilot Studio
  • Vložený WebChat s autentizovanými konverzacemi

WebChat s autentizací Autentizovaný WebChat s „Authenticate with Microsoft“. V UI to sice nevidíte, ale ověření proběhlo

Konfigurace je jednodušší hlavně proto, že Vám stačí jen:

  1. Jedna app registration pro Vaši webovou aplikaci (typ single-page application)
  2. V Copilot Studio zapnout „Authenticate with Microsoft“
  3. API oprávnění CopilotStudio.Copilots.Invoke

Žádné dvě app registrations. Žádné složité OAuth flow.

Mýtus #2: „Potřebuji uživatelův access token pro downstream API“

Tohle je druhý velký omyl.

Mýtus: „Můj agent musí volat vlastní API pod uživatelskými přihlašovacími údaji, takže potřebuji manual authentication, abych získal System.User.AccessToken.“

Realita: Custom connectors podporují SSO přes Entra ID authentication!

Co spousta lidí netuší: custom connectors umí nabídnout stejně hladký SSO/consent zážitek jako first-party konektory typu Office 365 Users nebo SharePoint. Když je správně nastavíte s Entra authentication, Váš custom connector:

  1. Uživatelům zobrazí consent card (místo obávaného connection manageru)
  2. Automaticky získá tokeny jménem uživatele
  3. Zavolá Vaše custom API pod uživatelskými přihlašovacími údaji
  4. Automaticky se postará o refresh tokenů

Consent card Ukázka consent card – dostupná i pro Vaše custom connectors

Update: Článek je už venku. Podívejte se na Seamless SSO with Custom Connectors, kde Dave přidává oficiální oznámení.

Přiznávám, že nastavení SSO/OBO pro custom connectors je trochu složitější, ale dělá se jen jednou pro každý connector – a pak už to funguje bez zásahu pro jakéhokoli agenta, který ho používá.

Proč jsou Custom Connectors lepší než ruční autentizace

Custom connectors mají oproti ruční autentizaci dvě zásadní výhody:

Vystavení tokenu: U ruční autentizace se System.User.AccessToken zpřístupní makerům. U Custom connector SSO zůstávají tokeny uvnitř connector frameworku a maker je nikdy neuvidí.

Omezení na jeden resource: Ruční autentizace podporuje jen jeden OAuth resource. Potřebujete zároveň Graph API pro SharePoint jako Knowledge a k tomu ještě vlastní API? Takhle to neuděláte.

Příklad: představte si, že stavíte HR asistenta, který potřebuje:

  • Vyhledávat dokumenty zaměstnanců v SharePointu (vyžaduje Graph API: Files.Read.All, Sites.Read.All)
  • Získat zůstatky dovolené z Vašeho HR API (vyžaduje Vaše API: api://your-hr-api/your-custom-scope)

U ruční autentizace platí, že i když nastavíte oba scopes, dostanete token jen se scopes pro jeden jediný resource (např. Graph).

S custom connectors byste použili:

  • SharePoint Knowledge (bez ručního nastavování scopes)
  • Custom HR connector (nastavený na api://your-hr-api/your-custom-scope)

Obojí funguje bez tření, každý konektor se svým vlastním resource. Vyřešeno.

Hlavní body

  • Manual auth se hodí hlavně pro B2C – použijte ho, když potřebujete providery mimo Entra (Google, Facebook, vlastní OAuth)
  • „Authenticate with Microsoft“ je jednodušší pro B2E – bez konfigurace pro Teams/M365/SharePoint, navíc umožní Tenant Graph Grounding
  • Web chat funguje i s „Authenticate with Microsoft“ – oficiální ukázky ukazují, jak na to
  • Custom connector SSO > Manual auth – více OAuth resources, žádné vystavování tokenů, stejně hladký consent
  • Single resource = největší omezení – Manual auth Vás uzamkne na jednu OAuth resource; custom connectors podporují neomezený počet resources

*Používali jste manual auth, i když to nebylo potřeba? Podělte se tady o své konfigurační horory



Tento článek vznikl s využitím materiálu z microsoft.github.io. Osobní postřehy a komentáře jsou moje vlastní.