Sdílet prostřednictvím

Ověřování a autorizace pro přístup k rozhraním API v Azure API Management

  • Článek

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

Tento článek je úvodem do bohaté a flexibilní sady funkcí ve službě API Management, které pomáhají zabezpečit přístup uživatelů ke spravovaným rozhraním API.

Ověřování a autorizace rozhraní API v API Management zahrnují zabezpečení kompletní komunikace klientských aplikací s bránou API Management a přes back-endová rozhraní API. V mnoha zákaznických prostředích je OAuth 2.0 upřednostňovaným protokolem autorizace rozhraní API. Služba API Management podporuje autorizaci OAuth 2.0 mezi klientem a bránou služby API Management, mezi bránou a back-endovým rozhraním API nebo obojím nezávisle.

Diagram znázorňující body interakce pro zabezpečení rozhraní API

SLUŽBA API Management podporuje další mechanismy ověřování a autorizace na straně klienta, které doplňují OAuth 2.0 nebo které jsou užitečné v případě, že autorizace OAuth 2.0 pro rozhraní API není možná. Způsob výběru z těchto možností závisí na vyspělosti prostředí rozhraní API vaší organizace, požadavcích na zabezpečení a dodržování předpisů a přístupu vaší organizace k zmírnění běžných hrozeb rozhraní API.

Důležité

Zabezpečení přístupu uživatelů k rozhraním API je jedním z mnoha aspektů zabezpečení prostředí API Management. Další informace najdete v tématu Standardní hodnoty zabezpečení Azure pro API Management.

Poznámka:

Ostatní komponenty služby API Management mají samostatné mechanismy pro zabezpečení a omezení přístupu uživatelů:

  • Ke správě instance služby API Management prostřednictvím řídicí roviny Azure spoléhá služba API Management na ID Microsoft Entra a řízení přístupu na základě role v Azure (RBAC).
  • Vývojářský portál SLUŽBY API Management podporuje několik možností , jak usnadnit zabezpečenou registraci a přihlašování uživatelů.

Ověřování versus autorizace

Tady je stručné vysvětlení ověřování a autorizace v kontextu přístupu k rozhraním API:

  • Ověřování – proces ověření identity uživatele nebo aplikace přistupujících k rozhraní API. Ověřování se může provádět pomocí přihlašovacích údajů, jako jsou uživatelské jméno a heslo, certifikátt nebo jednotné přihlašování (SSO), nebo jiné metody.

  • Autorizace – proces určení, jestli má uživatel nebo aplikace oprávnění k přístupu ke konkrétnímu rozhraní API, často prostřednictvím protokolu založeného na tokenech, jako je OAuth 2.0.

Poznámka:

Kvůli doplnění ověřování a autorizace by měl být přístup k rozhraním API zabezpečený také pomocí protokolu TLS, který chrání přihlašovací údaje nebo tokeny, které se používají k ověřování nebo autorizaci.

Koncepty OAuth 2.0

OAuth 2.0 je standardní autorizační architektura, která se běžně používá k zabezpečení přístupu k prostředkům, jako jsou webová rozhraní API. OAuth 2.0 omezuje akce toho, co klientská aplikace může provádět za uživatele, aniž by se sdílely přihlašovací údaje uživatele. I když OAuth 2.0 není ověřovací protokol, často se používá s OpenID Připojení (OIDC), který rozšiřuje OAuth 2.0 tím, že poskytuje funkce ověřování uživatelů a jednotného přihlašování.

Tok OAuth

Co se stane, když klientská aplikace volá rozhraní API s požadavkem zabezpečeným pomocí protokolu TLS a OAuth 2.0? Následuje zkrácený ukázkový tok:

  • Klient (volající aplikace nebo nosný) se ověřuje pomocí přihlašovacích údajů pro zprostředkovatele identity.

  • Klient získá časově omezený přístupový token (webový token JSON nebo JWT) z autorizačního serveru zprostředkovatele identity.

    Zprostředkovatel identity (například Microsoft Entra ID) je vystavitel tokenu a token obsahuje deklaraci cílové skupiny, která autorizuje přístup k serveru prostředků (například k back-endovému rozhraní API nebo samotné bráně služby API Management).

  • Klient volá rozhraní API a prezentuje přístupový token – například v autorizační hlavičce.

  • Server prostředků ověří přístupový token. Ověření je složitý proces, který zahrnuje kontrolu, že vystavitel a deklarace identity cílové skupiny obsahují očekávané hodnoty.

  • Na základě kritérií ověření tokenu se pak udělí přístup k prostředkům back-endového rozhraní API.

V závislosti na typu klientské aplikace a scénářů jsou k vyžádání a správě tokenů potřeba různé toky autorizace. Například tok autorizačního kódu a typ udělení se běžně používají v aplikacích, které volají webová rozhraní API. Přečtěte si další informace o tocích OAuth a scénářích aplikací v Microsoft Entra ID.

Scénáře autorizace OAuth 2.0 ve službě API Management

Scénář 1 – Klientská aplikace autorizuje přímo do back-endu

Běžným scénářem autorizace je, že volající aplikace požaduje přímý přístup k rozhraní API back-endu a v autorizační hlavičce brány zobrazí token OAuth 2.0. Azure API Management pak funguje jako "transparentní" proxy server mezi volajícím a back-endovým rozhraním API a předává token beze změny do back-endu. Rozsah přístupového tokenu je mezi volající aplikací a back-endovým rozhraním API.

Následující obrázek ukazuje příklad, ve kterém je ID Microsoft Entra zprostředkovatelem autorizace. Klientská aplikace může být jednostránkové aplikace (SPA).

Diagram znázorňující komunikaci OAuth, ve které je cílová skupina back-endem

I když přístupový token odeslaný společně s požadavkem HTTP je určený pro back-endové rozhraní API, služba API Management stále umožňuje hloubkovou ochranu. Nakonfigurujte například zásady pro ověření JWT, odmítnutí požadavků, které přicházejí bez tokenu, nebo token, který není platný pro zamýšlené back-endové rozhraní API. Službu API Management můžete také nakonfigurovat tak, aby kontrolovala další deklarace identity zájmu extrahované z tokenu.

Poznámka:

Pokud tímto způsobem zabezpečíte rozhraní API vystavené prostřednictvím služby Azure API Management pomocí OAuth 2.0, můžete službu API Management nakonfigurovat tak, aby vygenerovala platný token pro testovací účely jménem uživatele testovací konzoly webu Azure Portal nebo vývojářského portálu. Do instance služby API Management musíte přidat server OAuth 2.0 a povolit v rozhraní API nastavení autorizace OAuth 2.0. Další informace najdete v tématu Autorizace testovací konzoly portálu pro vývojáře konfigurací autorizace uživatelů OAuth 2.0.

Příklad:

Tip

Ve speciálním případě, když je přístup k rozhraní API chráněný pomocí ID Microsoft Entra, můžete nakonfigurovat zásadu validate-azure-ad-token pro ověření tokenu.

Scénář 2 – Klientská aplikace autorizuje službu API Management

V tomto scénáři služba API Management funguje jménem rozhraní API a volající aplikace požaduje přístup k instanci služby API Management. Rozsah přístupového tokenu je mezi volající aplikací a bránou služby API Management. Ve službě API Management nakonfigurujte zásadu (validate-jwt nebo validate-azure-ad-token) tak, aby token ověřila před tím, než brána předá požadavek do back-endu. Samostatný mechanismus obvykle zabezpečuje připojení mezi bránou a back-endovým rozhraním API.

V následujícím příkladu je Microsoft Entra ID znovu zprostředkovatelem autorizace a vzájemné ověřování TLS (mTLS) zabezpečuje připojení mezi bránou a back-endem.

Diagram znázorňující komunikaci OAuth, kde cílová skupina je brána služby API Management

Existují různé důvody, proč to udělat. Příklad:

  • Back-end je starší rozhraní API, které nejde aktualizovat, aby podporovalo OAuth.

    Služba API Management by měla být nejprve nakonfigurovaná tak, aby ověřila token (minimálně kontrola deklarací identity vystavitele a cílové skupiny). Po ověření použijte jednu z několika dostupných možností pro zabezpečení dalších připojení ze služby API Management, jako je vzájemné ověřování TLS (mTLS). Viz Možnosti na straně služby, dále v tomto článku.

  • Kontext vyžadovaný back-endem není možné navázat z volajícího.

    Jakmile služba API Management úspěšně ověří token přijatý od volajícího, potřebuje získat přístupový token pro back-endové rozhraní API pomocí vlastního kontextu nebo kontextu odvozeného z volající aplikace. Tento scénář lze provést pomocí následujících:

  • Organizace chce přijmout standardizovaný přístup k autorizaci.

    Bez ohledu na mechanismy ověřování a autorizace v back-endech rozhraní API se organizace můžou rozhodnout konvergovat na OAuth 2.0 pro standardizovaný přístup autorizace na front-endu. Brána služby API Management umožňuje konzistentní konfiguraci autorizace a běžné prostředí pro uživatele rozhraní API s vývojem back-endů organizace.

Scénář 3: Služba API Management autorizuje back-end

Pomocí spravovaných připojení (dříve označovaných jako autorizace) používáte správce přihlašovacích údajů ve službě API Management k autorizaci přístupu k jednomu nebo více back-endům nebo službám SaaS, jako jsou LinkedIn, GitHub nebo jiné back-endy kompatibilní s OAuth 2.0. V tomto scénáři uživatel nebo klientská aplikace odešle požadavek na bránu služby API Management s přístupem k bráně řízenou pomocí zprostředkovatele identity nebo jiných možností na straně klienta. Prostřednictvím konfigurace zásad pak uživatel nebo klientská aplikace deleguje ověřování a autorizaci back-endu do služby API Management.

V následujícím příkladu se mezi klientem a bránou používá klíč předplatného a GitHub je zprostředkovatel přihlašovacích údajů pro back-endové rozhraní API.

Diagram znázorňující autorizaci back-endové služby SaaS pomocí připojení spravovaného ve správci přihlašovacích údajů

S připojením k poskytovateli přihlašovacích údajů služba API Management získá a aktualizuje tokeny pro přístup k rozhraní API v toku OAuth 2.0. Připojení zjednodušují správu tokenů ve více scénářích, například:

  • Klientská aplikace může potřebovat autorizovat více back-endů SaaS k překladu více polí pomocí překladačů GraphQL.
  • Uživatelé se ověřují ve službě API Management jednotným přihlašováním od zprostředkovatele identity, ale autorizuje se k back-endovému poskytovateli SaaS (například LinkedIn) pomocí společného účtu organizace.
  • Klientská aplikace (nebo robot) potřebuje přístup k back-endovým zabezpečeným online prostředkům jménem ověřeného uživatele (například kontrola e-mailů nebo zadání objednávky).

Příklady:

Další možnosti zabezpečení rozhraní API

I když je autorizace upřednostňovaná a OAuth 2.0 se stala dominantní metodou povolení silné autorizace pro rozhraní API, poskytuje služba API Management několik dalších mechanismů pro zabezpečení nebo omezení přístupu mezi klientem a bránou (na straně klienta) nebo mezi bránou a back-endem (na straně služby). V závislosti na požadavcích organizace se můžou použít k doplnění OAuth 2.0. Případně je nakonfigurujte nezávisle, pokud jsou volající aplikace nebo back-endová rozhraní API starší nebo zatím nepodporují OAuth 2.0.

Možnosti na straně klienta

Mechanismus Popis Požadavky
mTLS Ověření certifikátu předloženého připojujícím se klientem a kontrola vlastností certifikátu vůči certifikátu spravovanému ve službě API Management Certifikát může být uložený v trezoru klíčů.
Omezení IP adres volajícího Filtrování (povolit nebo odepřít) volání z konkrétních IP adres nebo rozsahů adres Slouží k omezení přístupu k určitým uživatelům nebo organizacím nebo k provozu z upstreamových služeb.
Klíč předplatného Omezení přístupu k jednomu nebo několika rozhraním API na základě předplatného služby API Management Kromě jiné metody ověřování nebo autorizace doporučujeme použít klíč předplatného (API). Klíč předplatného není silnou formou ověřování, ale použití klíče předplatného může být užitečné v určitých scénářích, například sledování využití rozhraní API jednotlivých zákazníků nebo udělení přístupu ke konkrétním produktům rozhraní API.

Tip

Pro hloubkovou ochranu se důrazně doporučuje nasadit upstream brány firewall webových aplikací instance služby API Management. Použijte například Aplikace Azure Gateway nebo Azure Front Door.

Možnosti na straně služby

Mechanismus Popis Požadavky
Ověřování spravované identity Ověřte se v back-endovém rozhraní API pomocí spravované identity přiřazené systémem nebo přiřazenou uživatelem. Doporučeno pro omezený přístup k chráněnému back-endovému prostředku získáním tokenu z ID Microsoft Entra.
Ověřování certifikátů Ověřte se v back-endovém rozhraní API pomocí klientského certifikátu. Certifikát může být uložený v trezoru klíčů.
Základní ověřování Ověřte se v back-endovém rozhraní API pomocí uživatelského jména a hesla předávaného prostřednictvím autorizační hlavičky. Nedoporučujeme, pokud jsou k dispozici lepší možnosti.

Další kroky