Sdílet prostřednictvím


Informace o přihlašovacích údajích rozhraní API a správci přihlašovacích údajů

PLATÍ PRO: Všechny úrovně služby API Management

Aby vám pomohla spravovat přístup k back-endovým rozhraním API, vaše instance služby API Management zahrnuje správce přihlašovacích údajů. Pomocí správce přihlašovacích údajů můžete spravovat, ukládat a řídit přístup k přihlašovacím údajům rozhraní API z vaší instance služby API Management.

Poznámka:

  • V současné době můžete pomocí správce přihlašovacích údajů nakonfigurovat a spravovat připojení (dříve označovaná jako autorizace) pro rozhraní API OAuth 2.0 back-endu.
  • Ve Správci přihlašovacích údajů nejsou zavedeny žádné zásadní změny. Poskytovatelé přihlašovacích údajů a připojení OAuth 2.0 využívají stávající rozhraní API pro autorizaci a poskytovatele prostředků v rámci správy API.

Poznámka:

V současné době tato funkce není dostupná v pracovních prostorech.

Spravovaná připojení pro rozhraní API OAuth 2.0

Pomocí správce přihlašovacích údajů můžete výrazně zjednodušit proces ověřování a autorizace uživatelů, skupin a instančních objektů v jednom nebo několika back-endových službách nebo službách SaaS, které používají OAuth 2.0. Pomocí správce přihlašovacích údajů služby API Management můžete snadno nakonfigurovat OAuth 2.0, souhlas, získat tokeny, ukládat tokeny do mezipaměti v úložišti přihlašovacích údajů a obnovovat tokeny bez zápisu jednoho řádku kódu. Pomocí zásad přístupu delegujte ověřování na instanci služby API Management, instanční objekty, uživatele nebo skupiny. Základní informace o OAuth 2.0 najdete v tématu Microsoft Identity Platform a tok autorizačního kódu OAuth 2.0.

Tato funkce umožňuje publikování rozhraní API s klíčem předplatného nebo bez něj, použití autorizací OAuth 2.0 pro back-end služby a snížení nákladů na vývoj při vzestupu, implementaci a udržování bezpečnostních funkcí s integrací služeb.

Diagram správce přihlašovacích údajů služby API Management a podporovaných zprostředkovatelů identity SaaS

Příklady případů použití

Pomocí připojení OAuth spravovaných ve službě API Management se zákazníci můžou snadno připojit k poskytovatelům SaaS nebo back-endovým službám, které používají OAuth 2.0. Několik příkladů:

  • Snadno se připojte k back-endu SaaS připojením uloženého autorizačního tokenu a požadavků na proxy server.

  • Proxy server zpracovává požadavky na webové aplikace Azure App Service nebo backend Azure Functions připojením autorizačního tokenu, který může později odesílat požadavky do backendu SaaS pomocí logiky transformace.

  • Přesměrování požadavků na serverové systémy federace GraphQL připojením několika přístupových tokenů k usnadnění federace.

  • Zveřejnění koncového bodu načtení tokenu, získání tokenu v mezipaměti a volání back-endu SaaS jménem uživatele z libovolného výpočetního prostředí; Například konzolová aplikace nebo démon Kubernetes. Zkombinujte svou oblíbenou sadu SaaS SDK v podporovaném jazyce.

  • Bezobslužné scénáře Azure Functions při připojování k několika back-endům SaaS

  • Durable Functions se dostává o krok blíže k Logic Apps díky připojení SaaS.

  • S připojeními OAuth 2.0 může každé rozhraní API ve službě API Management fungovat jako vlastní konektor Logic Apps.

Jak funguje správce přihlašovacích údajů?

Přihlašovací údaje tokenu ve správci pověření se skládají ze dvou částí: správa a runtime.

  • Součástí správy ve správci přihlašovacích údajů je nastavení a konfigurace zprostředkovatele přihlašovacích údajů pro tokeny OAuth 2.0, povolení toku souhlasu pro zprostředkovatele identity a nastavení jednoho nebo více připojení k zprostředkovateli přihlašovacích údajů pro přístup k přihlašovacím údajům. Podrobnosti najdete v tématu Správa připojení.

  • Část runtime používá zásadu get-authorization-context k načtení a uložení přístupových a obnovovacích tokenů připojení. Když přijde volání do služby API Management a get-authorization-context zásada se spustí, nejprve ověří, jestli je existující autorizační token platný. Pokud vypršela platnost autorizačního tokenu, služba API Management pomocí toku OAuth 2.0 aktualizuje uložené tokeny od zprostředkovatele identity. Přístupový token se pak použije k autorizaci přístupu k back-endové službě. Podrobnosti najdete v tématu Doba běhu připojení.

Kdy použít správce přihlašovacích údajů?

Tady jsou tři scénáře použití správce přihlašovacích údajů.

Scénář konfigurace

Po konfiguraci zprostředkovatele přihlašovacích údajů a připojení může správce rozhraní API připojení otestovat. Správce rozhraní API nakonfiguruje testovací back-endové rozhraní API OAuth tak, aby používalo zásadu get-authorization-context pomocí spravované identity instance. Správce rozhraní API pak může otestovat připojení voláním testovacího rozhraní API.

Diagram počátečního scénáře konfigurace pro správce přihlašovacích údajů

Bezobslužný scénář

Ve výchozím nastavení při vytvoření připojení jsou zásady přístupu a připojení předem nakonfigurované pro spravovanou identitu instance služby API Management. Pokud chcete takové připojení použít, můžou se různí uživatelé přihlásit k klientské aplikaci, jako je statická webová aplikace, která pak volá back-endové rozhraní API vystavené prostřednictvím služby API Management. K provedení tohoto volání jsou připojení použity s využitím get-authorization-context zásady. Vzhledem k tomu, že volání rozhraní API používá předkonfigurované připojení, které nesouvisí s kontextem uživatele, vrátí se stejná data všem uživatelům.

Diagram scénáře spravované identity pro správce přihlašovacích údajů

Scénář účasti (delegovaný uživatelem)

Pokud chcete uživatelům klientských aplikací (například statických webových aplikací) povolit zjednodušené ověřování, které volají back-endová rozhraní API SaaS, která vyžadují kontext uživatele, můžete povolit přístup k připojení jménem identity uživatele nebo skupiny Microsoft Entra. V takovém případě se nakonfigurovaný uživatel musí přihlásit a poskytnout souhlas jenom jednou a instance služby API Management vytvoří a bude po tom spravovat připojení. Když služba API Management získá příchozí volání, které se má přesměrovat do externí služby, připojí přístupový token z připojení k požadavku. To je ideální pro případ, kdy jsou požadavky rozhraní API a odpovědi zaměřené na jednotlivce (například načítání informací o profilu specifickém pro uživatele).

Diagram scénáře delegovaného uživatelem pro správce přihlašovacích údajů

Jak nakonfigurovat správce přihlašovacích údajů?

Požadavky

  • Pro instanci služby API Management musí být povolená identita přiřazená spravovaným systémem.

  • Instance služby API Management musí mít odchozí připojení k internetu na portu 443 (HTTPS).

Dostupnost

  • Všechny úrovně služby API Management

  • Není podporováno v bráně na vlastním serveru

  • Není podporováno v suverénních cloudech ani v následujících oblastech: australiacentral, australiacentral2, indiacentral

Podrobné příklady

Bezpečnostní aspekty

Přístupový token a další tajné kódy (například tajné kódy klienta) se šifrují pomocí šifrování obálky a ukládají se v interním víceklientovém úložišti. Data se šifrují pomocí AES-128 pomocí klíče, který je jedinečný pro jednotlivá data. Tyto klíče se šifrují asymetricky pomocí hlavního certifikátu uloženého ve službě Azure Key Vault a každý měsíc se obměňují.

Omezení

Prostředek Omezení
Maximální počet zprostředkovatelů přihlašovacích údajů na instanci služby 1000
Maximální počet připojení pro zprostředkovatele přihlašovacích údajů 10 000
Maximální počet zásad přístupu na připojení 100
Maximální počet žádostí o autorizaci za minutu na jedno připojení 250

Nejčastější dotazy

Kdy se obnovují přístupové tokeny?

Pro připojení typu autorizačního kódu se přístupové tokeny aktualizují následujícím způsobem:

get-authorization-context Při spuštění zásady za běhu služba API Management zkontroluje, jestli je uložený přístupový token platný. Pokud platnost tokenu vypršela nebo brzy vyprší, služba API Management použije obnovovací token k načtení nového přístupového tokenu a nového obnovovacího tokenu z nakonfigurovaného zprostředkovatele identity. Pokud vypršela platnost obnovovacího tokenu, vyvolá se chyba a připojení musí být před tím, než bude fungovat, znovu autorizováno.

Co se stane, když vyprší platnost tajného klíče klienta u zprostředkovatele identity?

Za běhu nemůže služba API Management načíst nové tokeny a dojde k chybě.

  • Pokud je připojení typu autorizačního kódu, je potřeba aktualizovat tajný klíč klienta na úrovni zprostředkovatele přihlašovacích údajů.

  • Pokud je připojení typu přihlašovací údaje klienta, je potřeba aktualizovat tajný klíč klienta na úrovni připojení.

Podporuje se tato funkce pomocí služby API Management spuštěné uvnitř virtuální sítě?

Ano, pokud je povolené odchozí připojení na portu 443 ke značce služby AzureConnectors . Další informace najdete v tématu Referenční informace o konfiguraci virtuální sítě.

Co se stane, když se odstraní zprostředkovatel přihlašovacích údajů?

Odstraní se také všechna základní připojení a zásady přístupu.

Jsou přístupové tokeny uložené ve službě API Management v mezipaměti?

Ve vrstvách služby Classic a v2 se přístupový token ukládá do mezipaměti instance služby API Management až do tří minut před vypršením platnosti tokenu. Pokud je přístupový token kratší než tři minuty od vypršení platnosti, doba uložená v mezipaměti bude do vypršení platnosti přístupového tokenu.

Přístupové tokeny nejsou uloženy v mezipaměti na úrovni Consumption.