Sdílet prostřednictvím


Připojení OAuth 2.0 ve Správci přihlašovacích údajů – podrobnosti o procesu a toky

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

Tento článek obsahuje podrobnosti o tocích procesu pro správu připojení OAuth 2.0 pomocí správce přihlašovacích údajů ve službě Azure API Management. Toky procesů jsou rozdělené do dvou částí: správa a modul runtime.

Základní informace o správci přihlašovacích údajů ve službě API Management najdete v tématu o správci přihlašovacích údajů a přihlašovacích údajích rozhraní API ve službě API Management.

Správa připojení

Část správy připojení ve správci přihlašovacích údajů se stará o nastavení a konfiguraci zprostředkovatele přihlašovacích údajů pro tokeny OAuth 2.0, povolení toku souhlasu pro poskytovatele 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.

Následující obrázek shrnuje tok procesu pro vytvoření připojení ve službě API Management, který používá typ udělení autorizačního kódu.

Diagram znázorňující tok procesu pro vytvoření přihlašovacích údajů

Krok Description
1 Klient odešle žádost o vytvoření zprostředkovatele přihlašovacích údajů.
2 Vytvoří se zprostředkovatel přihlašovacích údajů a zpět se odešle odpověď.
3 Klient odešle žádost o vytvoření připojení.
4 Připojení ion se vytvoří a odpověď se odešle zpět s informacemi, že připojení není připojené.
5 Klient odešle žádost o načtení přihlašovací adresy URL pro spuštění souhlasu OAuth 2.0 u zprostředkovatele přihlašovacích údajů. Požadavek obsahuje adresu URL po přesměrování, která se má použít v posledním kroku.
6 Odpověď se vrátí s přihlašovací adresou URL, která by se měla použít ke spuštění toku souhlasu.
7 Klient otevře prohlížeč s přihlašovací adresou URL, kterou jste zadali v předchozím kroku. Prohlížeč se přesměruje na tok souhlasu OAuth 2.0 zprostředkovatele přihlašovacích údajů.
8 Po schválení souhlasu se prohlížeč přesměruje s autorizačním kódem na adresu URL přesměrování nakonfigurovanou u zprostředkovatele přihlašovacích údajů.
9 Služba API Management pomocí autorizačního kódu načítá přístup a obnovovací tokeny.
10 SLUŽBA API Management přijímá tokeny a šifruje je.
11 Služba API Management přesměruje na zadanou adresu URL z kroku 5.

Zprostředkovatel přihlašovacích údajů

Při konfiguraci zprostředkovatele přihlašovacích údajů si můžete vybrat mezi různými poskytovateli OAuth a udělit typy (autorizační kód nebo přihlašovací údaje klienta). Každý poskytovatel vyžaduje konkrétní konfigurace. Důležité věci, které je potřeba mít na paměti:

  • Konfigurace zprostředkovatele přihlašovacích údajů může mít pouze jeden typ udělení.
  • Jedna konfigurace zprostředkovatele přihlašovacích údajů může mít více připojení.

Poznámka:

U obecného zprostředkovatele OAuth 2.0 je možné použít další zprostředkovatele identity, které podporují standardy toku OAuth 2.0.

Když nakonfigurujete zprostředkovatele přihlašovacích údajů, správce přihlašovacích údajů na pozadí vytvoří úložiště přihlašovacích údajů, které slouží k ukládání do mezipaměti přístupových tokenů OAuth 2.0 zprostředkovatele a obnovovacích tokenů.

Připojení pro zprostředkovatele přihlašovacích údajů

Aby klientské aplikace mohli přistupovat k poskytovateli a používat je, potřebují připojení k zprostředkovateli přihlašovacích údajů. Dané připojení povoluje zásady přístupu založené na identitách ID Microsoft Entra. Pro poskytovatele můžete nakonfigurovat více připojení.

Proces konfigurace připojení se liší podle nakonfigurovaného udělení a je specifický pro konfiguraci zprostředkovatele přihlašovacích údajů. Pokud například chcete nakonfigurovat ID Microsoft Entra tak, aby používalo oba typy udělení, jsou potřeba dvě konfigurace zprostředkovatele přihlašovacích údajů. Následující tabulka shrnuje dva typy grantů.

Typ udělení Popis
Autorizační kód Vázáno na kontext uživatele, což znamená, že uživatel musí odsouhlasit připojení. Pokud je obnovovací token platný, může služba API Management načíst nové přístupové a obnovovací tokeny. Pokud se obnovovací token stane neplatným, musí uživatel znovu provést ověření. Všichni zprostředkovatelé přihlašovacích údajů podporují autorizační kód. Další informace
Přihlašovací údaje klienta Není vázán na uživatele a často se používá ve scénářích mezi aplikacemi. Pro typ udělení přihlašovacích údajů klienta není vyžadován žádný souhlas a připojení není neplatné. Další informace

U připojení na základě typu udělení autorizačního kódu je nutné ověřit poskytovatele a udělit souhlas s autorizací. Po úspěšném přihlášení a autorizaci poskytovatelem přihlašovacích údajů zprostředkovatel vrátí platné přístupové a obnovovací tokeny, které jsou šifrované a uložené službou API Management.

Zásady přístupu

Pro každé připojení nakonfigurujete jednu nebo více zásad přístupu. Zásady přístupu určují, které identity ID Microsoft Entra můžou získat přístup k vašim přihlašovacím údajům za běhu. Připojení v současné době podporují přístup pomocí instančních objektů, identity instance služby API Management, uživatelů a skupin.

Identita Popis Zaměstnanecké výhody Důležité informace
Instanční objekt Identita, jejíž tokeny je možné použít k ověření a udělení přístupu ke konkrétním prostředkům Azure, když organizace používá ID Microsoft Entra. Pomocí instančního objektu se organizace vyhýbají vytváření fiktivních uživatelů pro správu ověřování, když potřebují přístup k prostředku. Instanční objekt je identita Microsoft Entra, která představuje registrovanou aplikaci Microsoft Entra. Umožňuje užší přístup ke scénářům připojení a delegování uživatelů. Není svázaný s konkrétní instancí služby API Management. Spoléhá na Microsoft Entra ID pro vynucování oprávnění. Získání autorizačního kontextu vyžaduje token ID Microsoft Entra.
Spravovaná identita <Your API Management instance name> Tato možnost odpovídá spravované identitě svázané s vaší instancí služby API Management. Ve výchozím nastavení se přístup poskytuje spravované identitě přiřazené systémem pro odpovídající instanci služby API Management. Identita je svázaná s vaší instancí služby API Management. Každý, kdo má přístup přispěvatele k instanci služby API Management, má přístup k libovolnému připojení, které uděluje oprávnění spravované identity.
Uživatelé nebo skupiny Uživatelé nebo skupiny ve vašem tenantovi Microsoft Entra ID. Umožňuje omezit přístup na konkrétní uživatele nebo skupiny uživatelů. Vyžaduje, aby uživatelé měli účet Microsoft Entra ID.

Modul runtime připojení

Část modulu runtime vyžaduje, aby se pro zásady nakonfigurovala rozhraní API OAuth 2.0 back-endu get-authorization-context . Za běhu zásady načítají a ukládají přístupové a obnovovací tokeny z úložiště přihlašovacích údajů, které pro zprostředkovatele nastavila služba API Management. Když volání přijde 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 přihlašovacích údajů. Přístupový token se pak použije k autorizaci přístupu k back-endové službě.

Během provádění zásad se také ověřuje přístup k tokenům pomocí zásad přístupu.

Následující obrázek ukazuje příklad toku procesu pro načtení a uložení autorizačních a obnovovacích tokenů na základě připojení, které používá typ udělení autorizačního kódu. Po načtení tokenů se do back-endového rozhraní API provede volání.

Diagram znázorňující tok procesu pro načtení tokenu za běhu

Krok Description
1 Klient odešle požadavek do instance služby API Management.
2 Zásady get-authorization-context zkontrolují, jestli je přístupový token platný pro aktuální připojení.
3 Pokud vypršela platnost přístupového tokenu, ale obnovovací token je platný, služba API Management se pokusí načíst nový přístup a aktualizovat tokeny z nakonfigurovaného zprostředkovatele přihlašovacích údajů.
4 Zprostředkovatel přihlašovacích údajů vrátí přístupový token i obnovovací token, které jsou šifrované a uložené ve službě API Management.
5 Po načtení tokenů se přístupový token připojí pomocí set-header zásady jako autorizační hlavičky k odchozímu požadavku back-endovému rozhraní API.
6 Odpověď se vrátí do služby API Management.
7 Odpověď se vrátí klientovi.