Dela via

Hantera token för Nolltillit

I Zero Trust-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 principen noll förtroende för 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. Ge endast auktoriserad 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 MFA, hanterade enheter och rätt platser.

Gör det enkelt för dina kunder att hantera auktoriseringar till din app. Minska användarskapande och konfigurationskostnader och 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 appprovisionering eller HR-driven provisionering i Microsoft Entra ID.

Använd token-attribut i dina appar

Använd anspråk i ID-token för att förbättra användarupplevelsen i ditt program som nycklar i en databas. Ge åtkomst till klientprogrammet. ID-token är det kärntillägg som OpenID Connect (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 tenanten 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. Använd dessa anspråksvärden för att ansluta dina data tillbaka till användarens ID i Microsoft Entra-ID.
  • Anspråket sub är ett värde som är oföränderligt och unikt identifierar 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ånget offline_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.

Microsoft Graph definierar till exempel det User.Read omfång 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 upprepa autentisering. 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. Påståendet exp är den tidpunkt då ID-tokenen löper ut och tidpunkten efter vilken du inte längre kan använda ID-tokenen 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 kontrollerar du att token är giltiga och oexpirerade. Målgruppsanropet (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 upprätthåller 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 förfallotid för Microsoft Entra-ID-token. Följ identitetsproviderns förfallotid för token för att säkerställa att användarens sessioner aldrig är längre än de principer som identitetsprovidern dikterar.

Cachelagrar och uppdaterar token

Kom ihåg att cachelagra tokenen på rätt sätt. MSAL cachelagrar token automatiskt, men token har livslängd. Använd token genom hela deras livstid och cachelagra dem på rätt sätt. Om du upprepade gånger ber om samma token leder begränsningen till att programmet blir mindre responsivt. Om din app missbrukar utfärdandet av token förlängs tiden 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 uppfriskningstoken för att hämta ytterligare åtkomsttoken för andra resurser. Uppfräschnings-token är bundna till en kombination av användare och klient (inte till en resurs eller en tenant). Du kan använda en refresh-token för att hämta åtkomsttoken för vilken kombination av resurser och klientorganisationer som helst, 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 misslyckas ett anrop för att hämta en token 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 leta i en åtkomsttoken måste du hitta alternativ till att leta 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 när systemet inte beviljar behörighet. Eftersom du kanske missar dessa enskilda fall är det bättre att söka efter en klassificerare som användarinteraktion i stället för att gräva i enskilda felkoder.

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

Nästa steg

  • Last updated on