Autentisera användare för Nolltillit

Den här artikeln hjälper dig som utvecklare att lära dig metodtips för att autentisera dina programanvändare i Nolltillit programutveckling. Förbättra alltid programsäkerheten med de Nolltillit principerna om lägsta behörighet och verifiera explicit.

ID-token i användarautentisering

När du behöver en användare för att autentisera till din app, i stället för att samla in ett användarnamn och lösenord, kan ditt program begära en identitetstoken (ID). Att autentisera användare via Microsofts identitetsplattform undviker säkerhetsrisker som uppstår när ditt program behåller autentiseringsuppgifterna. Om en felaktig aktör bryter mot eller komprometterar ditt program finns det inga användarnamn och motsvarande lösenord i din app när du begär ID-token.

Den Microsofts identitetsplattform ID-token är en del av OIDC-standarden (OpenID Connect) som anger ID-token som JSON-webbtoken (JWT). Den långa JWT-strängen består av tre komponenter:

1. Rubrikanspråk. Huvudanspråken som finns i ID-token inkluderar typ (typanspråk), alg (algoritm för signering av token) och kid (tumavtryck för den offentliga nyckeln för att verifiera tokens signatur).
2. Nyttolastanspråk. Nyttolasten eller brödtexten (den mellersta delen av en JSON-webbtoken) innehåller en serie namnattributpar. Standarden kräver att det finns ett anspråk med iss (utfärdarens namn) som går till programmet som utfärdade token (anspråket aud, eller målgrupp).
3. Signatur. Microsoft Entra-ID genererar den tokensignatur som appar kan använda för att verifiera att token är oförändrad och du kan lita på den.

Följande exempel på en ID-token visar information om användaren och bekräftar autentiseringen för att använda programmet.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
}.
.[Signature]

ID-token i åtkomsthantering

Om du vill ta emot ditt program-ID (klient)-ID registrerar du din app med Microsofts identitetsplattform. När du får en token med ett målgruppsanspråk (aud) som matchar appens klient-ID autentiserades den identifierade användaren i token till din app. IT-administratörer kan tillåta att alla användare i klientorganisationen använder din app. De kan tillåta en grupp där användaren är medlem att använda din app.

Om du får en token vars målgruppsanspråk skiljer sig från appens klient-ID avvisar du omedelbart token. Användaren autentiseras inte till din app eftersom de har loggat in på en annan app. Kontrollera alltid att användaren har behörighet att använda din app.

Dessa anspråksinformation är viktiga vid användarautentisering:

• En JSON-webbtoken är giltig tills den upphör att gälla. Anspråket exp (förfallodatum) anger när token upphör att gälla. Om den aktuella tiden är före tiden i anspråket exp är token giltig.
• Betrakta inte användaren som autentiserad före den tid som anges i anspråket nbf (inte före tid). Tokens nbf tid och exp tid definierar tokens giltiga livslängd. När förfallotiden är nära förestående kontrollerar du att du får en ny ID-token.
• sub (ämnesanspråket) är en unik identifierare för en programanvändare. Samma användare har ett annat sub anspråk för andra appar. Om du vill lagra data för att associera tillbaka till en användare och förhindra att en angripare gör den associationen använder du ämnesanspråket. Eftersom den inte exponerar användarens Microsoft Entra-identitet är det det mest privata sättet att associera data med en användare. Anspråket sub är oföränderligt.
• Om du vill dela information mellan flera program använder du kombinationen av klientorganisations-ID(tid) och objekt-ID(oid) anspråk som är unika för användaren. Det kombinerade klientorganisations-ID:t och objekt-ID:t är oföränderliga.
• Oavsett vad som händer med en individs identitet förblir anspråken sub, oidoch tid oföränderliga. Allt om användaren kan ändras och du kan fortfarande stänga av dina data för att identifiera användaren baserat på ämnet eller de kombinerade tid anspråken och oid anspråken.

Autentisering med OIDC

För att demonstrera användarautentisering ska vi titta på program som använder OIDC för att autentisera en användare. Samma principer gäller för appar som använder SAML (Security Assertion Markup Language) eller WS-Federation.

En app autentiserar användaren när programmet begär en ID-token från Microsofts identitetsplattform. Arbetsbelastningar (program som inte har användare närvarande utan i stället körs som tjänster, bakgrundsprocesser, daemoner) hoppar över det här steget.

Du bör alltid fråga tyst om den här token först. Om du tyst vill hämta en token i Microsoft Authentication Libraries (MSAL) kan din app börja med AcquireTokenSilent -metoden. Om din app kan autentiseras utan att störa användaren tar den emot den begärda ID-token.

Om Microsofts identitetsplattform inte kan slutföra begäran utan att interagera med användaren måste appen återgå till MSAL-metodenAcquireTokenInteractive. Om du vill hämta en token interaktivt utför du begäran genom att öppna en webbyta till en adress under domänen https://login.microsoftonline.com .

Från den här webbytan har användaren en privat konversation med Microsofts identitetsplattform. Appen har ingen vy över den här konversationen och har inte heller någon kontroll över konversationen. Microsofts identitetsplattform kan be om ett användar-ID och lösenord, multifaktorautentisering (MFA), lösenordslös autentisering eller annan autentiseringsinteraktion som IT-administratören eller användaren har konfigurerat.

Ditt program får en ID-token efter att användaren utfört nödvändiga autentiseringssteg. När din app tar emot token kan du vara säker på att Microsofts identitetsplattform autentiserade användaren. Om din app inte tar emot en ID-token autentiserade Microsofts identitetsplattform inte användaren. Tillåt inte att oautentiserade användare fortsätter till skyddade områden i din app.

Det är bästa praxis för program att skapa en session för en användare när den har fått en ID-token från Microsoft Entra-ID. I den ID-token som en app tar emot, ett förfalloanspråk (exp) med en Unix-tidsstämpel. Den här tidsstämpeln anger på eller efter förfallotiden för vilken appen inte får acceptera JWT för bearbetning. Använd den här förfallotiden för token för att öka livslängden för dina användarsessioner. Anspråket exp spelar en avgörande roll för att hålla en explicit verifierad användare framför appen med rätt behörighet och under rätt tid.

Enkel inloggning support

Med autentisering med enkel inloggning (SSO) kan användarna logga in med en uppsättning autentiseringsuppgifter till flera oberoende programvarusystem. Med enkel inloggning kan programutvecklare inte kräva att en användare loggar in på varje program separat och upprepade gånger. Utvecklarna är kärnan i enkel inloggning och ser till att alla program på användarens enhet delar den webbyta som autentiserar användaren. Artefakter på webbytan (till exempel sessionstillstånd och cookies) efter lyckad autentiseringsenhet.

Som du ser i följande diagram är det enklaste användningsfallet för en delad webbyta en app som körs i en webbläsare (till exempel Microsoft Edge, Google Chrome, Firefox, Safari). Webbläsarflikar delar SSO-tillståndet.

Diagramrubrik: Webbläsare – enklaste fallet. Längst upp i diagrammet visas en molnform som innehåller en Microsoft Entra-ID-ikon. Under molnformen finns en ruta. Att ansluta molnformen och rutan är en linje med en pil i varje ände. Lådetiketten är "Håll mig inloggad, sparar cookies för SSO-tillstånd över anrop.". Inuti rutan, till vänster, finns en ikon som ser ut som en cookie. Under cookien är bildtexten "Privat konversation med användaren". Under undertexten finns en ikon som representerar användaren. Till vänster om dessa tre komponenter, inuti rutan, finns en annan ruta. Den interna lådetiketten är "Flikar". Under etiketten finns fyra fyrkantiga rutor som representerar webbläsarfönster på flikar.

Microsofts identitetsplattform hanterar SSO-tillståndet i en specifik webbläsare om inte användaren har olika webbläsare öppna på samma enhet. I Windows 10 och senare har Microsofts identitetsplattform inbyggt stöd för webbläsarens SSO Microsoft Edge. När användaren har loggat in på Windows tillåter boenden i Google Chrome (via Windows 10-kontotillägget) och Mozilla Firefox v91+ (via en webbläsarinställning) varje webbläsare att dela SSO-tillståndet för Själva Windows.

Som du ser i följande diagram är det interna användningsfallet för program mer komplicerat.

Diagramrubrik: Inbyggda program – inbäddade webbläsare – ingen enkel inloggning. Längst upp i diagrammet visas en molnform som innehåller en Microsoft Entra-ID-ikon. Längst ned i diagrammet finns fyra rutor fördelade vågrätt. Längst ned till höger i varje ruta finns en ikon som representerar en användare. Inuti var och en av rutorna finns en representation av webbläsarfönster, inklusive en cookieikon och en jordglobsikon. Att ansluta var och en av de fyra rutorna till molnformen är en linje med en pil i varje ände.

Auth Broker-metod

Ett vanligt mönster är att varje inbyggd app har en egen inbäddad WebView som hindrar den från att delta i enkel inloggning. För att hantera det här scenariot använder Microsoft Entra ID en autentiseringskoordinatormetod (auth broker) för inbyggda program enligt följande diagram.

Diagramrubrik: Auth broker-metod. Längst upp i diagrammet visas en molnform som innehåller en Microsoft Entra-ID-ikon. Under molnformen finns en rektangelform med etiketten Auth Broker. Rektangelns form innehåller en cookieikon och en jordglobsikon. Att ansluta molnformen och rektangelns form är en linje med en pil i varje ände. Längst ned i diagrammet finns fyra rutor fördelade vågrätt. Längst ned till höger i varje ruta finns en ikon som representerar en användare. Ikoner i varje ruta representerar webbläsarfönster. Att ansluta var och en av de fyra rutorna till rektangelformen är en linje med en pil i varje ände.

Med en auth broker på plats skickar program autentiseringsbegäranden till asynkron meddelandekö i stället för direkt till Microsofts identitetsplattform. På så sätt blir koordinatorn den delade ytan för all autentisering på enheten.

Förutom att tillhandahålla en delad yta ger autentiseringskoordinatorn andra fördelar. När Nolltillit används kanske företag bara vill att program ska köras från företagshanterade enheter. Exempel på hantering av företagsenheter är fullständiga MDM (Mobile Enhetshantering) och scenarier där användare tar med sina egna enheter som deltar i hantering av mobilprogram (MAM).

Avsiktligt isolerar underliggande operativsystem (OS) webbläsare. Utvecklare behöver en närmare anslutning till operativsystemet för att ha fullständig åtkomst till enhetsinformation. I Windows är autentiseringskoordinatorn Windows Web Account Manager (WAM). På andra enheter är auth broker antingen Microsoft Authenticator-appen (för enheter som kör iOS eller Android) eller Företagsportal App (för enheter som kör Android). Program får åtkomst till auth broker med MSAL. I Windows kan en app komma åt WAM utan MSAL. MSAL är dock det enklaste sättet för appar att komma åt auth broker (särskilt appar som inte är Universell Windows-plattform appar).

Auth-koordinatorer fungerar i kombination med Microsoft Entra-ID för att använda primära uppdateringstoken (PRT) som minskar användarnas behov av att autentisera flera gånger. PRT kan avgöra om användaren finns på en hanterad enhet. Microsoft Entra ID kräver auth brokers eftersom det introducerar Proof of Possession tokens, ett säkrare alternativ över de ägartoken som är vanliga idag.

Nästa steg

• Felsöka Microsoft Entra-åtkomsttoken: Verifiera en åtkomsttoken beskriver hur du kontrollerar att vissa fält matchar posten när du har en Microsoft Entra-åtkomsttoken.
• Öka motståndskraften för autentiserings- och auktoriseringsprogram som du utvecklar serie adresserar appar som använder Microsofts identitetsplattform och Microsoft Entra-ID. De innehåller vägledning för klient- och tjänstprogram som fungerar för en inloggad användare och daemonprogram som fungerar för deras egen räkning. De innehåller metodtips för att använda token och anropa resurser.
• Anpassa token beskriver den information som du kan ta emot i Microsoft Entra-token och hur du kan anpassa token.
• Konfigurera gruppanspråk och approller i token visar hur du konfigurerar dina appar med approlldefinitioner och tilldelar säkerhetsgrupper till approller.
• Skapa appar som skyddar identiteten via behörigheter och medgivande ger en översikt över bästa praxis för behörigheter och åtkomst.