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.
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:
- Vytvořit dvě samostatné app registration (podle best practices)
- Zorientovat se v méně intuitivních nastaveních typu
Token Exchange URL(a upřímně, ani to není tak úplně URL…) - 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:
- React Web Chat Sample - Kompletní implementace v Reactu s ověřením přes Entra ID
- Web Client Sample - Varianta ve „vanilla“ JavaScriptu
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
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:
- Jedna app registration pro Vaši webovou aplikaci (typ single-page application)
- V Copilot Studio zapnout „Authenticate with Microsoft“
- 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:
- Uživatelům zobrazí consent card (místo obávaného connection manageru)
- Automaticky získá tokeny jménem uživatele
- Zavolá Vaše custom API pod uživatelskými přihlašovacími údaji
- Automaticky se postará o refresh tokenů
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í.