Offentliga klientprogram och konfidentiella klientprogram
Microsoft Authentication Library (MSAL) definierar två typer av klienter. offentliga klienter och konfidentiella klienter. En klient är en programvaruentitet som har en unik identifierare tilldelad av en identitetsprovider. Klienttyperna särskiljs av deras möjlighet att autentisera säkert med auktoriseringsservern och att lagra känslig identitetsbevisinformation så att den inte kan nås eller kännas till för en användare inom ramen för dess åtkomst.
| Offentliga klientappar | Konfidentiella klientappar |
|---|---|
 Skrivbordsapp |
 Webbapp |
 Webbläsarlöst API |
 Webb-API |
 Mobilapp |
Tjänst/daemon |
Offentlig klient och konfidentiell klientauktorisering
När vi undersöker den offentliga eller konfidentiella karaktären hos en viss klient utvärderar vi klientens förmåga att bevisa sin identitet för auktoriseringsservern. Detta är viktigt eftersom auktoriseringsservern måste kunna lita på klientens identitet för att kunna utfärda åtkomsttoken.
Offentliga klientprogram körs på enheter, till exempel skrivbords-, webbläsarlösa API:er, mobilappar eller webbläsarappar på klientsidan. De kan inte vara betrodda för att bevara programhemligheter på ett säkert sätt, så de kan bara komma åt webb-API:er för användarens räkning. Varje gång källan eller kompilerad bytekod för en viss app överförs var som helst där den kan läsas, demonteras eller på annat sätt inspekteras av ej betrodda parter, är det en offentlig klient. Eftersom de också bara stöder offentliga klientflöden och inte kan lagra konfigurationstidshemligheter kan de inte ha klienthemligheter.
Konfidentiella klientprogram körs på servrar, till exempel webbappar, webb-API-appar eller tjänst-/daemon-appar. De anses vara svåra att komma åt av användare eller angripare och kan därför lagra konfigurationstidshemligheter tillräckligt för att bekräfta bevis på dess identitet. Klient-ID:t exponeras via webbläsaren, men hemligheten skickas endast i den bakre kanalen och exponeras aldrig direkt.
När ska du aktivera tillåta ett offentligt klientflöde i din appregistrering?
När du har fastställt vilken typ av klientprogram du skapar kan du bestämma om du vill aktivera det offentliga klientflödet i din appregistrering. Tillåt som standard att offentligt klientflöde i appregistreringen inaktiveras om du eller utvecklaren inte skapar ett offentligt klientprogram och använder följande OAuth-auktoriseringsprotokoll eller funktioner:
| OAuth-auktoriseringsprotokoll/funktion | Typ av offentligt klientprogram | Exempel/anteckningar |
|---|---|---|
| Intern autentisering | Microsoft Entra Externt ID-program som kräver fullständig anpassning av användargränssnittet, inklusive designelement, logotypplacering och layout, vilket säkerställer ett konsekvent och varumärkesanpassat utseende. | Obs! Intern autentisering är endast tillgängligt för appregistreringar i Externa ID-klientorganisationer i Microsoft Entra. Läs mer här |
| Enhetskodflöde | Program som körs på indatabegränsade enheter, till exempel en smart-TV, IoT-enhet eller en skrivare | |
| Flöde för lösenordsautentiseringsuppgifter för resursägare | Program som hanterar lösenord som användare anger direkt, i stället för att omdirigera användare till entra värdbaserad inloggningswebbplats och låta Entra hantera användarlösenord på ett säkert sätt. | Microsoft rekommenderar att du inte använder ROPC-flödet. I de flesta scenarier är säkrare alternativ, till exempel auktoriseringskodflödet, tillgängliga och rekommenderade. |
| Windows-integrerat autentiseringsflöde | Skrivbords- eller mobilprogram som körs i Windows eller på en dator som är ansluten till en Windows-domän (Microsoft Entra-ID eller Microsoft Entra-ansluten) med Windows Integrated Auth Flow i stället för Web Account Manager | Ett skrivbords- eller mobilprogram som ska loggas in automatiskt när användaren har loggat in på Windows PC-systemet med en Microsoft Entra-autentiseringsuppgift |
Hemligheter och deras betydelse för att bevisa identitet
Följande är några exempel på hur en klient kan bevisa sin identitet för auktoriseringsservern:
- Hanterade identiteter för Azure-resurser – För autentiseringsscenarier med endast appar har program- och tjänstutvecklare som bygger på Azure möjlighet att avlasta hemlig hantering, rotation och skydd till själva plattformen. Med hanterade identiteter tillhandahålls och tas identiteter bort med Azure-resurser och ingen, inklusive den globala administratören, kan komma åt de underliggande autentiseringsuppgifterna. Genom att använda hanterade identiteter kan du förhindra risken att läcka hemligheter och låta leverantören hantera säkerheten åt dig.
- Klient-ID och hemlighet – I det här mönstret genereras ett par värden av auktoriseringsservern när en klient registreras. Klient-ID:t är ett offentligt värde som identifierar programmet, medan klienthemligheten är ett konfidentiellt värde som används för att bevisa programmets identitet.
- Att bevisa innehav av ett certifikat – PKI (Public Key Infrastructure), som innehåller standarder som X.509, är den grundläggande tekniken som möjliggör säker kommunikation via Internet och utgör ryggraden i internetsekretessen. PKI används för att utfärda digitala certifikat som verifierar identiteten för parter som är involverade i onlinekommunikation och är den underliggande tekniken som driver protokoll som HTTPS, som ofta används för att skydda webbtrafik. På samma sätt kan certifikat användas för att skydda tjänst-till-tjänst-kommunikation (S2S) i Azure genom att möjliggöra ömsesidig autentisering mellan tjänsterna. Detta innebär att varje tjänst presenterar ett certifikat för den andra som ett sätt att bevisa sin identitet.
- Presentation av en signerad försäkran – Används i arbetsbelastningsidentitetsfederation, signerade intyg möjliggör utbyte av en betrodd identitetsprovidertoken från tredje part med Microsofts identitetsplattform för att hämta åtkomsttoken för att anropa Microsoft Entra-skyddade resurser. Arbetsbelastningsidentitetsfederation kan användas för att aktivera olika federationsscenarier, inklusive Azure Kubernetes Service, Amazon Web Services EKS, GitHub Actions med mera.
När spelar det någon roll att bevisa klientidentitet?
Att bevisa klientidentitet spelar roll när det finns ett behov av att verifiera både autentiteten och auktoriseringen av ett klientprogram innan åtkomst till känsliga data eller resurser beviljas. Vissa exempel inkluderar:
- Kontrollera API-åtkomst – Om du har ett API som mäts (till exempel för fakturering) eller exponerar känsliga data eller resurser kontrollerar du klientens identitet innan du beviljar åtkomst. Detta är till exempel viktigt när du ser till att endast auktoriserade program har åtkomst till API:et och att rätt kund debiteras för sin användning av MÄT-API:et.
- Skydda användare från apppersonifiering – Om du har ett tjänstdistribuerat, användaranslutet program (till exempel en serverdelsdriven webbapp) som har åtkomst till känsliga data eller tjänster, kan användning av klienthemligheter för att skydda de resurser som används av programmet hindra dåliga aktörer från att personifiera en legitim klient för att nätfiltera användare och utfiltra data eller missbruksåtkomst.
- S2S-kommunikation – Om du har flera serverdelstjänster (till exempel underordnade API:er) som behöver kommunicera med varandra kan du verifiera identiteten för varje tjänst för att säkerställa att de har behörighet att endast komma åt nödvändiga resurser för att utföra sin funktion.
I allmänhet är det viktigt att bevisa klientidentitet när det finns ett behov av att autentisera och auktorisera en klient oberoende av eller utöver en användare.
Konfidentiella klienter: metodtips för att hantera hemligheter
Använd hanterade identiteter för att förenkla distribution och säkerhet – Hanterade identiteter ger en automatiskt hanterad identitet i Microsoft Entra-ID som program kan använda när de ansluter till resurser som stöder Microsoft Entra-autentisering. Program kan använda hanterade identiteter för att hämta apptoken endast för Microsoft Entra-ID utan att behöva hantera autentiseringsuppgifter. Detta kan ta bort många av de komplexiteter som är associerade med hemlig hantering, samtidigt som du ökar din säkerhet och återhämtning. Om du använder hanterade identiteter tas de flesta, om inte alla av följande metodtips, redan hand om dig.
Använd säker lagring – Lagra klienthemligheter på en säker plats, till exempel Key Vault eller en krypterad konfigurationsfil. Undvik att lagra klienthemligheter i klartext eller som incheckade filer till versionskontrollsystem.
Begränsa åtkomst – Begränsa åtkomsten till klienthemligheter till endast auktoriserad personal. Använd rollbaserad åtkomstkontroll för att begränsa åtkomsten till klienthemligheter till endast de som behöver den för att utföra sina operativa uppgifter.
Rotera klienthemligheter – Rotation av klienthemligheter efter behov eller schemalagt kan minimera risken för att en komprometterad hemlighet används för att få obehörig åtkomst. När den tillämpas påverkas det tidsintervall under vilket en nyckel föreslås fortsätta att användas av styrkan hos den kryptografiska algoritm som används och/eller efterlevnaden av standarder eller regelefterlevnadsmetoder.
Använd långa hemligheter och stark kryptering – Nära relaterad till föregående punkt, med hjälp av starka krypteringsalgoritmer för data både under överföring (på tråden) och i vila (på disk) hjälper till att säkerställa att hemligheter med hög entropi fortfarande inte kommer att vara råa. Algoritmer som AES-128 (eller senare) kan hjälpa till att skydda vilande data, medan RSA-2048 (eller senare) effektivt kan skydda data under överföring. På grund av cybersäkerhetens ständigt växande karaktär är det alltid bästa praxis att konsultera dina säkerhetsexperter och regelbundet granska valet av algoritm.
Undvik hårdkodning av hemligheter – Hårdkoda inte klienthemligheter i källkoden. Om du undviker hemligheter i källkoden kan du minimera värdet för dåliga aktörer som får åtkomst till källkoden. Det kan också förhindra att sådana hemligheter oavsiktligt skickas till osäkra lagringsplatser eller görs tillgängliga för projektdeltagare som kan ha källåtkomst, men inte hemlig åtkomst.
Övervaka lagringsplatser för läckta hemligheter – Det är olyckligt att dåliga incheckningar inträffar när du hanterar källkod. Git-förincheckningskrokar är ett föreslaget sätt att förhindra oavsiktliga incheckningar, men är inte heller en ersättning för övervakning. Automatiserad övervakning av lagringsplatser kan identifiera läckta hemligheter och med en plan för att rotera komprometterade autentiseringsuppgifter kan det bidra till att minska säkerhetsincidenter.
Övervaka misstänkt aktivitet – Övervaka loggar och spårningsloggar för misstänkt aktivitet relaterad till klienthemligheter. Om möjligt kan du använda automatiserade aviseringar och svarsprocesser för att meddela personal och definiera oförutsedda händelser för ovanlig aktivitet relaterad till klienthemligheter.
Skapa dina program med klienthemlighet i åtanke – Din säkerhetsmodell är bara lika stark som den svagaste länken i kedjan. Vidarebefordra inte säkerhetsautentiseringsuppgifter eller token från konfidentiella till offentliga klienter, eftersom detta kan flytta klienthemliga data till en offentlig klient, vilket tillåter personifiering av den konfidentiella klienten.
Använd uppdaterade bibliotek och SDK:er från betrodda källor – Microsofts identitetsplattform tillhandahåller olika klient- och server-SDK:er och mellanprogram som är utformade för att öka produktiviteten samtidigt som dina program hålls säkra. Bibliotek som Microsoft.Identity.Web gör det enklare att lägga till autentisering och auktorisering i webbappar och API:er på Microsofts identitetsplattform. Genom att hålla beroendena uppdaterade ser du till att dina program och tjänster drar nytta av de senaste säkerhetsinnovationerna och uppdateringarna.
Jämföra klienttyperna och deras funktioner
Följande är några likheter och skillnader mellan offentliga och konfidentiella klientappar:
- Båda apptyperna underhåller en cache för användartoken och kan hämta en token tyst (när token finns i cacheminnet). Konfidentiella klientappar har också en apptokencache för token som hämtas av själva appen.
- Båda apptyperna kan hantera användarkonton och hämta ett konto från cacheminnet för användartoken, hämta ett konto från dess identifierare eller ta bort ett konto.
- I MSAL har offentliga klientappar fyra sätt att hämta en token via separata autentiseringsflöden. Konfidentiella klientappar har bara tre sätt att hämta en token och ett sätt att beräkna URL:en för identitetsprovidern auktorisera slutpunkten. Klient-ID :t skickas en gång när programmet byggs och behöver inte skickas igen när appen hämtar en token. Mer information finns i hämta token.
Offentliga klienter är användbara för att aktivera användardelegering till skyddade resurser men kan inte bevisa sin egen programidentitet. Konfidentiella klienter kan å andra sidan utföra både användar- och programautentisering och auktorisering och måste byggas med säkerhet i åtanke för att säkerställa att deras hemligheter inte delas med offentliga klienter eller andra tredje parter.
I vissa fall, till exempel S2S-kommunikation, hjälper infrastruktur som hanterade identiteter avsevärt till att förenkla utvecklingen och distributionen av tjänster och tar bort mycket av den komplexitet som vanligtvis är associerad med hemlig hantering. När hanterade identiteter inte kan användas är det viktigt att ha principer, förebyggande åtgärder och oförutsedda händelser på plats för att skydda hemligheter och hantera säkerhetsincidenter som är relaterade till dem.
Se även
Mer information om programkonfiguration och instansiering finns i: