Hantera token för Nolltillit

  • Artikel

I Nolltillit programutveckling är det viktigt att specifikt definiera programmets avsikt och dess krav på resursåtkomst. Din app bör endast begära den åtkomst som krävs för att fungera som avsett. Den här artikeln hjälper dig som utvecklare att bygga in säkerhet i dina program med ID-token, åtkomsttoken och säkerhetstoken som din app kan ta emot från Microsofts identitetsplattform.

Se till att ditt program följer Nolltillit principen om lägsta behörighet och förhindrar användning på sätt som äventyrar din avsikt. Begränsa användaråtkomst med JUST-In-Time och Just-Enough-Access (JIT/JEA), riskbaserade adaptiva principer och dataskydd. Avgränsa appens känsliga och kraftfulla avsnitt och ge endast behörig användaråtkomst till dessa områden. Begränsa användare som kan använda ditt program och de funktioner som de har i din app.

Skapa minsta möjliga behörighet i hur ditt program hanterar ID-token som det tar emot från Microsofts identitetsplattform. Med information i ID-token kan du kontrollera att en användare är den användaren påstår sig vara. Användaren eller organisationen kan ange autentiseringsvillkor som att tillhandahålla en MFA, använda en hanterad enhet och vara på rätt plats.

Gör det enkelt för dina kunder att hantera auktoriseringar till din app. Minska användarens etableringskostnader och behovet av manuella processer. Med automatisk användaretablering kan IT-administratörer automatisera skapandet, underhållet och borttagningen av användaridentiteter i målidentitetslager. Dina kunder kan basera automatisering på ändringar av användare och grupper med appetablering eller HR-driven etablering i Microsoft Entra-ID.

Använda tokenanspråk i dina appar

Använd anspråk i ID-token för UX i ditt program, som nycklar i en databas och ge åtkomst till klientprogrammet. ID-token är det kärntillägg som OpenID Anslut (OIDC) gör till OAuth 2.0. Din app kan ta emot ID-token tillsammans med eller i stället för åtkomsttoken.

I standardmönstret för auktorisering av säkerhetstoken gör en utfärdad ID-token att programmet kan ta emot information om användaren. Använd inte ID-token som en auktoriseringsprocess för att komma åt resurser. Auktoriseringsservern utfärdar ID-token som innehåller anspråk med användarinformation som innehåller följande.

  • Målgruppsanspråket (aud) är appens klient-ID. Acceptera endast token för ditt API-klient-ID.
  • Anspråket tid är ID:t för klientorganisationen som utfärdade token. Anspråket oid är ett oföränderligt värde som unikt identifierar användaren. Använd den unika kombinationen av anspråken tid och oid som en nyckel när du behöver associera data med användaren. Du kan använda dessa anspråksvärden för att ansluta dina data tillbaka till användarens ID i Microsoft Entra-ID.
  • Anspråket sub är ett oföränderligt värde som unikt identiteter användaren. Ämnesanspråket är också unikt för ditt program. Om du använder anspråket sub för att associera data med användaren är det omöjligt att gå från dina data och ansluta dem till en användare i Microsoft Entra-ID.

Dina appar kan använda omfånget openid för att begära en ID-token från Microsofts identitetsplattform. OIDC-standarden styr omfånget openid tillsammans med formatet och innehållet i ID-token. OIDC anger följande omfång:

  • Använd omfånget openid för att logga in användaren och lägga till ett sub anspråk i ID-token. Dessa omfång ger ett användar-ID som är unikt för appen och användaren och som anropar UserInfo-slutpunkten.
  • Omfånget email lägger till ett email anspråk som innehåller användarens e-postadress till ID-token.
  • Omfånget profile lägger till anspråk med grundläggande profilattribut för användaren (namn, användarnamn) till ID-token.
  • Omfånget offline_access gör att appen kan komma åt användardata även när användaren inte finns.

Microsoft Authentication Library (MSAL) lägger alltid till openid, e-post och profile omfång för varje tokenbegäran. Därför returnerar MSAL alltid en ID-token och en åtkomsttoken för varje anrop till AcquireTokenSilent eller AcquireTokenInteractive. MSAL begär alltid omfånget offline_access . Microsofts identitetsplattform returnerar offline_access alltid omfång även om den begärande appen inte anger omfångetoffline_access.

Microsoft använder OAuth2-standarden för att utfärda åtkomsttoken. OAuth2-standarden säger att du får en token, men den anger inte tokenformatet eller vad som behöver finnas i token. När ditt program behöver komma åt en resurs som Microsoft Entra-ID skyddar bör det använda ett omfång som resursen har definierat.

Till exempel definierar Microsoft Graph omfånget User.Read som tillåter programmet att komma åt den aktuella användarens fullständiga användarprofil och klientorganisationens namn. Microsoft Graph definierar behörigheter för alla funktioner som är tillgängliga i api:et.

Vid auktorisering returnerar Microsofts identitetsplattform en åtkomsttoken till ditt program. När du anropar resursen tillhandahåller appen den här token som en del av auktoriseringshuvudet för HTTP-begäran till API:et.

Hantera tokenlivslängder

Program kan skapa en session för en användare när autentiseringen har slutförts med Microsoft Entra-ID. Hantering av användarsessioner styr hur ofta en användare behöver omautentiseras. Dess roll för att hålla en explicit verifierad användare framför appen med rätt behörighet och under rätt tid är avgörande. Sessionslivslängden måste baseras på anspråket exp i ID-token. Anspråket exp är den tidpunkt då ID-token upphör att gälla och den tid efter vilken du inte längre kan använda token för att autentisera användaren.

Respektera alltid tokens livslängd enligt tokensvaret för åtkomsttoken eller anspråket exp i ID-token. Villkor som styr tokens livslängd kan innehålla inloggningsfrekvens för ett företag. Programmet kan inte konfigurera tokens livslängd. Du kan inte begära en tokenlivslängd.

I allmänhet måste token vara giltiga och oexpirerade. Målgruppsanspråket (aud) måste matcha ditt klient-ID. Kontrollera att token kommer från en betrodd utfärdare. Om du har ett API för flera klienter kan du välja att filtrera så att endast specifika klienter kan anropa ditt API. Se till att du framtvingar tokens livslängd. Kontrollera anspråken nbf (inte före) och exp (förfallodatum) för att säkerställa att den aktuella tiden ligger inom dessa två anspråksvärden.

Sikta inte på exceptionellt långa eller korta sessionslivslängder. Låt den beviljade ID-tokenlivslängden driva det här beslutet. Att hålla appens sessioner aktiva utöver tokens giltighet strider mot de regler, principer och problem som drev en IT-administratör att ange en varaktighet för tokens giltighet för att förhindra obehörig åtkomst. Korta sessioner försämrar användarupplevelsen och ökar inte nödvändigtvis säkerhetsstatusen. Med populära ramverk som ASP.NET kan du ange tidsgränser för sessioner och cookies från Microsoft Entra-ID:ts ID-tokens förfallotid. Genom att följa identitetsproviderns förfallotid för token ser du till att användarens sessioner aldrig är längre än de principer som identitetsprovidern dikterar.

Cachelagring och uppdatera token

Kom ihåg att cachelagrar token på rätt sätt. MSAL cachelagrar token automatiskt, men token har livslängd. Använd token under hela livslängden och cachelagrar dem på rätt sätt. Om du upprepade gånger ber om samma token blir begränsningen att programmet blir mindre dynamiskt. Om din app missbrukar utfärdandet av token förlängs den tid som krävs för att utfärda nya token till din app.

MSAL-bibliotek hanterar information om OAuth2-protokollet, inklusive mekaniken för att uppdatera token. Om du inte använder MSAL kontrollerar du att ditt bibliotek använder uppdateringstoken på ett effektivt sätt.

När klienten hämtar en åtkomsttoken för åtkomst till en skyddad resurs får den en uppdateringstoken. Använd uppdateringstoken för att hämta nya åtkomst-/uppdateringstokenpar när den aktuella åtkomsttoken upphör att gälla. Använd uppdateringstoken för att hämta extra åtkomsttoken för andra resurser. Uppdateringstoken är bundna till en kombination av användare och klient (inte till en resurs eller klientorganisation). Du kan använda en uppdateringstoken för att hämta åtkomsttoken över valfri kombination av resurser och klientorganisationer där din app har behörigheter.

Hantera tokenfel och buggar

Ditt program bör aldrig försöka verifiera, avkoda, inspektera, tolka eller undersöka innehållet i en åtkomsttoken. Dessa åtgärder är strikt ansvaret för resurs-API:et. Om appen försöker undersöka innehållet i en åtkomsttoken är det mycket troligt att programmet bryts när Microsofts identitetsplattform utfärdar krypterade token.

Sällan kan ett anrop för att hämta en token misslyckas på grund av problem som nätverks-, infrastruktur- eller autentiseringstjänstfel eller avbrott. Öka återhämtningsförmågan för autentiseringsupplevelsen i ditt program om ett tokeninsamlingsfel inträffar genom att följa dessa metodtips:

  • Cachelagrar och skyddar token lokalt med kryptering.
  • Skicka inte säkerhetsartefakter som token runt på icke-säkerhetskanaler.
  • Förstå och agera på undantag och tjänstsvar från identitetsprovidern.

Utvecklare har ofta frågor om att leta i token för att felsöka problem som att få ett 401-fel från att anropa resursen. Eftersom fler krypterade token hindrar dig från att titta i en åtkomsttoken behöver du hitta alternativ till att titta i åtkomsttoken. Vid felsökning ger tokensvaret som innehåller åtkomsttoken den information du behöver.

I koden söker du efter felklasser i stället för enskilda felfall. Hantera till exempel användarinteraktion som krävs i stället för enskilda fel där systemet inte har beviljat behörighet. Eftersom du kan missa dessa enskilda fall är det bättre att söka efter en klassificerare som användarinteraktion i stället för att gå in i enskilda felkoder.

Du kan behöva gå tillbaka till AcquireTokenInteractive och tillhandahålla anspråksutmaningar som AcquireTokenSilent samtalet kräver. Detta säkerställer effektiv hantering av den interaktiva begäran.

Nästa steg