Dela via

Autentisering och auktorisering till API:er i Azure API Management

  • Artikel

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.

Diagram som visar interaktionspunkter för att skydda API:er.

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

Diagram som visar OAuth-kommunikation där målgruppen är serverdelen.

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

Diagram som visar OAuth-kommunikation där målgruppen är API Management-gatewayen.

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.

Diagram som visar auktorisering för serverdelstjänsten SaaS med hjälp av en anslutning som hanteras i autentiseringshanteraren.

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:

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