Autentisering och auktorisering till API:er i Azure API Management
GÄLLER FÖR: Alla API Management-nivåer
Den här artikeln är en introduktion till en omfattande, flexibel uppsättning funktioner i API Management som hjälper dig att skydda användarnas åtkomst till hanterade API:er.
API-autentisering och auktorisering i API Management omfattar att skydda kommunikationen från slutpunkt till slutpunkt för klientappar till API Management-gatewayen och till serverdels-API:er. I många kundmiljöer är OAuth 2.0 det föredragna API-auktoriseringsprotokollet. API Management stöder OAuth 2.0-auktorisering mellan klienten och API Management-gatewayen, mellan gatewayen och serverdels-API:et, eller båda oberoende av varandra.
API Management stöder andra autentiserings- och auktoriseringsmekanismer på klientsidan och på tjänstsidan som kompletterar OAuth 2.0 eller som är användbara när OAuth 2.0-auktorisering för API:er inte är möjligt. Hur du väljer bland de här alternativen beror på mognaden för din organisations API-miljö, dina säkerhet och efterlevnadskrav och organisationens metod för att minimera vanliga API-hot.
Viktigt!
Att skydda användarnas åtkomst till API:er är en av många överväganden för att skydda din API Management miljö. Mer information finns i Azures säkerhetsbaslinje för API Management.
Kommentar
Andra API Management-komponenter har separata mekanismer för att skydda och begränsa användaråtkomst:
- För att hantera API Management-instansen via Azure-kontrollplanet förlitar sig API Management på Microsoft Entra ID och rollbaserad åtkomstkontroll i Azure (RBAC).
- API Management-utvecklarportalen har stöd för flera alternativ för att underlätta säker registrering och inloggning för användare.
Autentisering kontra auktorisering
Här är en kort förklaring av autentisering och auktorisering i samband med åtkomst till API:er:
Autentisering – Processen för att verifiera identiteten för en användare eller app som har åtkomst till API:et. Autentisering kan göras via autentiseringsuppgifter som användarnamn och lösenord, ett certifikat eller via enkel inloggning (SSO) eller andra metoder.
Auktorisering – Processen för att avgöra om en användare eller app har behörighet att komma åt ett visst API, ofta via ett tokenbaserat protokoll som OAuth 2.0.
Kommentar
För att komplettera autentisering och auktorisering bör åtkomst till API:er också skyddas med hjälp av TLS för att skydda de autentiseringsuppgifter eller token som används för autentisering eller auktorisering.
OAuth 2.0-begrepp
OAuth 2.0 är ett standardauktoriseringsramverk som används ofta för att skydda åtkomsten till resurser, till exempel webb-API:er. OAuth 2.0 begränsar åtgärder för vad en klientapp kan utföra för resurser åt användaren, utan att någonsin dela användarens autentiseringsuppgifter. Även om OAuth 2.0 inte är ett autentiseringsprotokoll används det ofta med OpenID Anslut (OIDC), vilket utökar OAuth 2.0 genom att tillhandahålla användarautentisering och SSO-funktioner.
OAuth-flöde
Vad händer när en klientapp anropar ett API med en begäran som skyddas med TLS och OAuth 2.0? Följande är ett förkortat exempelflöde:
Klienten (den anropande appen eller innehavaren) autentiserar med autentiseringsuppgifter till en identitetsprovider.
Klienten hämtar en tidsbegränsad åtkomsttoken (en JSON-webbtoken eller JWT) från identitetsproviderns auktoriseringsserver.
Identitetsprovidern (till exempel Microsoft Entra-ID) är utfärdaren av token och token innehåller ett målgruppsanspråk som ger åtkomst till en resursserver (till exempel till ett serverdels-API eller till själva API Management-gatewayen).
Klienten anropar API:et och visar åtkomsttoken , till exempel i ett auktoriseringshuvud.
Resursservern verifierar åtkomsttoken. Validering är en komplex process som innehåller en kontroll av att utfärdaren och målgruppsanspråken innehåller förväntade värden.
Baserat på valideringskriterier för token beviljas åtkomst till resurser i serverdels-API:et.
Beroende på typen av klientapp och scenarier krävs olika auktoriseringsflöden för att begära och hantera token. Till exempel används auktoriseringskodflödet och beviljandetypen ofta i appar som anropar webb-API:er. Läs mer om OAuth-flöden och programscenarier i Microsoft Entra-ID.
OAuth 2.0-auktoriseringsscenarier i API Management
Scenario 1 – Klientappen auktoriserar direkt till serverdelen
Ett vanligt auktoriseringsscenario är när det anropande programmet begär åtkomst till serverdels-API:et direkt och visar en OAuth 2.0-token i ett auktoriseringshuvud till gatewayen. Azure API Management fungerar sedan som en "transparent" proxy mellan anroparen och serverdels-API:et och skickar token via oförändrad till serverdelen. Omfånget för åtkomsttoken ligger mellan det anropande programmet och serverdels-API:et.
Följande bild visar ett exempel där Microsoft Entra ID är auktoriseringsprovidern. Klientappen kan vara ett enkelsidigt program (SPA).
Även om åtkomsttoken som skickas tillsammans med HTTP-begäran är avsedd för serverdels-API:et, tillåter API Management fortfarande ett djupgående skydd. Konfigurera till exempel principer för att verifiera JWT, avvisa begäranden som tas emot utan en token eller en token som inte är giltig för det avsedda serverdels-API:et. Du kan också konfigurera API Management för att kontrollera andra anspråk av intresse som extraherats från token.
Kommentar
Om du skyddar ett API som exponeras via Azure API Management med OAuth 2.0 på det här sättet kan du konfigurera API Management för att generera en giltig token i testsyfte för en testkonsolanvändare i Azure-portalen eller utvecklarportalen. Du måste lägga till en OAuth 2.0-server i API Management-instansen och aktivera inställningarna för OAuth 2.0-auktorisering i API:et. Mer information finns i Auktorisera testkonsolen för utvecklarportalen genom att konfigurera användarauktorisering för OAuth 2.0.
Exempel:
Dricks
I specialfallet när API-åtkomst skyddas med hjälp av Microsoft Entra-ID kan du konfigurera policyn validate-azure-ad-token för tokenverifiering.
Scenario 2 – Klientappen auktoriserar TILL API Management
I det här scenariot agerar API Management-tjänsten för API:ets räkning och det anropande programmet begär åtkomst till API Management-instansen. Omfånget för åtkomsttoken är mellan det anropande programmet och API Management-gatewayen. I API Management konfigurerar du en princip (validate-jwt eller validate-azure-ad-token) för att verifiera token innan gatewayen skickar begäran till serverdelen. En separat mekanism skyddar vanligtvis anslutningen mellan gatewayen och serverdels-API:et.
I följande exempel är Microsoft Entra-ID återigen auktoriseringsprovidern, och ömsesidig TLS-autentisering (mTLS) skyddar anslutningen mellan gatewayen och serverdelen.
Det finns olika orsaker till detta. Till exempel:
Serverdelen är ett äldre API som inte kan uppdateras för att stödja OAuth
API Management bör först konfigureras för att verifiera token (kontrollera utfärdaren och målgruppsanspråken minst). Efter valideringen använder du ett av flera tillgängliga alternativ för att skydda vidare anslutningar från API Management, till exempel ömsesidig TLS-autentisering (mTLS). Se Alternativ för tjänstsidan senare i den här artikeln.
Den kontext som krävs av serverdelen är inte möjlig att upprätta från anroparen
När API Management har verifierat token som tagits emot från anroparen måste den hämta en åtkomsttoken för serverdels-API:et med hjälp av sin egen kontext eller kontext som härletts från det anropande programmet. Det här scenariot kan utföras med antingen:
En anpassad princip, till exempel skicka-begäran för att hämta en vidare åtkomsttoken som är giltig för serverdels-API:et från en konfigurerad identitetsprovider.
API Management-instansens egen identitet – skicka token från API Management-resursens systemtilldelade eller användartilldelade hanterade identitet till serverdels-API:et.
Organisationen vill använda en standardiserad auktoriseringsmetod
Oavsett autentiserings- och auktoriseringsmekanismerna på deras API-serverdelar kan organisationer välja att konvergera på OAuth 2.0 för en standardiserad auktoriseringsmetod i klientdelen. API Managements gateway kan aktivera konsekvent auktoriseringskonfiguration och en vanlig upplevelse för API-konsumenter när organisationens serverdelar utvecklas.
Scenario 3: API Management auktoriserar till serverdel
Med hanterade anslutningar (kallades tidigare auktoriseringar) använder du autentiseringshanteraren i API Management för att auktorisera åtkomst till en eller flera serverdelar eller SaaS-tjänster, till exempel LinkedIn, GitHub eller andra OAuth 2.0-kompatibla serverdelar. I det här scenariot skickar en användare eller klientapp en begäran till API Management-gatewayen, med gatewayåtkomst styrd med hjälp av en identitetsprovider eller andra alternativ på klientsidan. Sedan delegerar användaren eller klientappen serverdelsautentisering och auktorisering till API Management via principkonfiguration.
I följande exempel används en prenumerationsnyckel mellan klienten och gatewayen, och GitHub är providern för autentiseringsuppgifter för serverdels-API:et.
Med en anslutning till en provider för autentiseringsuppgifter hämtar API Management och uppdaterar token för API-åtkomst i OAuth 2.0-flödet. Anslut ions förenklar tokenhantering i flera scenarier, till exempel:
- En klientapp kan behöva auktorisera flera SaaS-serverdelar för att lösa flera fält med GraphQL-matchare.
- Användare autentiserar till API Management med enkel inloggning från sin identitetsprovider, men auktoriserar till en SaaS-serverdelsprovider (till exempel LinkedIn) med hjälp av ett gemensamt organisationskonto.
- En klientapp (eller robot) måste komma åt serverdelssäkrade onlineresurser för en autentiserad användares räkning (till exempel genom att kontrollera e-postmeddelanden eller göra en beställning).
Exempel:
- Konfigurera autentiseringshanteraren – Microsoft Graph API
- Konfigurera autentiseringshanteraren – GitHub API
- Konfigurera autentiseringshanteraren – användar delegerad åtkomst till serverdels-API:er
Andra alternativ för att skydda API:er
Även om auktorisering föredras och OAuth 2.0 har blivit den dominerande metoden för att aktivera stark auktorisering för API:er, tillhandahåller API Management flera andra mekanismer för att skydda eller begränsa åtkomsten mellan klient och gateway (klientsidan) eller mellan gateway och serverdel (tjänstsidan). Beroende på organisationens krav kan dessa användas för att komplettera OAuth 2.0. Du kan också konfigurera dem oberoende av varandra om de anropande programmen eller serverdels-API:erna är äldre eller ännu inte stöder OAuth 2.0.
Alternativ på klientsidan
Mekanism | beskrivning | Överväganden |
---|---|---|
mTLS | Verifiera certifikat som presenteras av den anslutande klienten och kontrollera certifikategenskaper mot ett certifikat som hanteras i API Management | Certifikatet kan lagras i ett nyckelvalv. |
Begränsa uppringarens IP-adresser | Filtrera (tillåt/neka) anrop från specifika IP-adresser eller adressintervall. | Använd för att begränsa åtkomsten till vissa användare eller organisationer eller till trafik från överordnade tjänster. |
Prenumerationsnyckel | Begränsa åtkomsten till en eller flera API:er baserat på en API Management-prenumeration | Vi rekommenderar att du använder en prenumerationsnyckel (API) utöver en annan autentiserings- eller auktoriseringsmetod. På egen hand är en prenumerationsnyckel inte en stark form av autentisering, men användning av prenumerationsnyckeln kan vara användbar i vissa scenarier, till exempel att spåra enskilda kunders API-användning eller bevilja åtkomst till specifika API-produkter. |
Dricks
För att skydda på djupet rekommenderar vi starkt att du distribuerar en brandvägg för webbprogram uppströms API Management-instansen. Du kan till exempel använda Azure Application Gateway eller Azure Front Door.
Alternativ på tjänstsidan
Mekanism | beskrivning | Överväganden |
---|---|---|
Hanterad identitetsautentisering | Autentisera till serverdels-API:et med en systemtilldelad eller användartilldelad hanterad identitet. | Rekommenderas för begränsad åtkomst till en skyddad serverdelsresurs genom att hämta en token från Microsoft Entra-ID. |
Certifikatautentisering | Autentisera till serverdels-API:et med hjälp av ett klientcertifikat. | Certifikatet kan lagras i nyckelvalvet. |
Grundläggande autentisering | Autentisera till serverdels-API:et med användarnamn och lösenord som skickas via ett auktoriseringshuvud. | Rekommenderas inte om det finns bättre alternativ. |
Nästa steg
- Läs mer om autentisering och auktorisering i Microsofts identitetsplattform.
- Lär dig hur du minimerar OWASP API-säkerhetshot med hjälp av API Management.