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

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.

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.

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.

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).

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.

Příklad:

• Ochrana rozhraní API ve službě Azure API Management s využitím ověřování OAuth 2.0 a Microsoft Entra ID

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.

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:

  • Vlastní zásady, jako je odeslání požadavku na získání přístupového tokenu od back-endového rozhraní API od nakonfigurovaného zprostředkovatele identity.

  • Vlastní identita instance služby API Management – předání tokenu ze spravované identity přiřazené systémem nebo přiřazené uživatelem prostředku služby API do back-endového rozhraní API.

• 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.

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:

• Konfigurace správce přihlašovacích údajů – Rozhraní Microsoft Graph API
• Konfigurace správce přihlašovacích údajů – rozhraní API GitHubu
• Konfigurace správce přihlašovacích údajů – delegovaný přístup uživatele k back-endovým rozhraním API

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

Možnosti na straně služby

Další kroky

• Přečtěte si další informace o ověřování a autorizaci na platformě Microsoft Identity Platform.
• Zjistěte, jak zmírnit bezpečnostní hrozby rozhraní API OWASP pomocí služby API Management.