Dela via

Välj en lösning för identitetshantering

  • Artikel

De flesta webbappar stöder autentisering för att säkerställa att användarna är de som de påstår sig vara. En användare kan vara en person eller en annan app. Hantering av åtkomst säkerställer att användarna bara kan se och ändra den information som de har behörighet att se och ändra. En slutanvändare bör till exempel inte ha åtkomst till den administrativa delen av en webbplats. Identity hanteringslösningar skapas för att hantera kraven för autentisering och auktoriseringsrelaterade uppgifter. Mer information om identitetshantering finns i Vad är identitets- och åtkomsthantering?. Många identitetshanteringslösningar för .NET-webbappar är tillgängliga, var och en med olika funktioner och krav att använda eller installera. Den här artikeln innehåller vägledning om hur du väljer rätt lösning.

Grundläggande identitetshantering med ASP.NET Core Identity

ASP.NET Core levereras med en inbyggd autentiseringsprovider: ASP.NET Core Identity. Providern innehåller API:er, användargränssnitt och serverdelsdatabaskonfiguration för att hantera användaridentiteter, lagra användarautentiseringsuppgifter och bevilja eller återkalla behörigheter. Andra funktioner som stöds är:

I de flesta scenarier kan detta vara den enda provider som behövs.

Om du vill veta mer:

I andra scenarier kan en server eller tjänst som hanterar autentisering och identitet vara fördelaktig.

Kontrollera om en OIDC-server behövs

Webbappar kräver ett sätt att komma ihåg tidigare åtgärder eftersom webben som standard är tillståndslös. Annars skulle användarna tvingas ange sina autentiseringsuppgifter varje gång de navigerar till en ny sida. Den vanliga lösningen för att komma ihåg tillstånd är cookies, en webbläsarbaserad mekanism för att lagra data. Webbservern skickar den första cookieoch sedan lagrar webbläsaren den och skickar tillbaka den med varje begäran. Detta görs automatiskt utan att utvecklaren behöver skriva någon kod. Cookies är enkla att använda och inbyggda i webbläsaren men är utformade för användning inom en enda webbplats eller webbdomän. Standardlösningen som är inbyggd i ASP.NET Core använder cookie-baserad autentisering.

Token är containrar med metadata som uttryckligen skickas genom rubrikerna eller brödtexten för HTTP-begäranden. Den största fördelen med token över cookies är att de inte är knutna till en specifik app eller domän. I stället är token vanligtvis signerade med asymmetrisk kryptografi. Till exempel utfärdar OIDC-servrar token med information om identitet med hjälp av JSON-webbtoken (JWT) format som inkluderar signering. Asymmetrisk kryptografi använder en kombination av en privat nyckel som bara är känd för undertecknaren och en offentlig nyckel som alla kan känna till. Token kan också krypteras.

Den signerade token kan inte manipuleras på grund av den privata nyckeln. Den offentliga nyckeln:

  • Gör det möjligt att verifiera token för att säkerställa att den inte har ändrats.
  • Garanterar att den genererades av entiteten med den privata nyckeln.

Den största nackdelen med att använda token är att de kräver en tjänst (vanligtvis en OIDC-server) för att både utfärda och tillhandahålla validering av token. Tjänsten måste installeras, konfigureras och underhållas.

En vanlig orsak till att en OIDC-server krävs är för program som exponerar webbaserade API:er som används av andra appar. För exponerade webbaserade API:er anses klientgränssnitt som SPA (Single Page Applications), mobila klienter och skrivbordsklienter vara del av samma app. SPA-exempel är Angular, React och Blazor WebAssembly. Om andra appar än din webbapp eller klient-UIs måste göra ett säkert API-anrop till din app, vill du förmodligen använda token. Om du bara har klient-UIs ger ASP.NET Core Identity möjlighet att hämta en token under autentiseringen. Autentiseringstoken som utfärdats av ASP.NET Core Identity:

  • Kan användas av mobil- och skrivbordsklienter. Cookies föredras framför token för både säkerhet och enkelhet.
  • Lämpar sig inte för att hantera åtkomst från appar från tredje part.

En annan orsak till att en OIDC-server krävs är för att dela inloggningar med andra appar. Den här funktionen kallas ofta enkel inloggningoch gör att användarna kan:

  • Logga in en gång med en webbapps formulär.
  • Använd de resulterande autentiseringsuppgifterna för att autentisera med andra appar utan att behöva logga in igen eller välja ett annat lösenord.

En OIDC-server är vanligtvis att föredra för att tillhandahålla en säker och skalbar lösning för enkel inloggning.

För appar som inte delar inloggningar med andra appar är det enklaste sättet att snabbt skydda en app att använda den inbyggda ASP.NET Core Identity-providern. Annars krävs en OIDC-server som tillhandahålls av en identitetshanteringslösning från tredje part. OIDC-servrar är tillgängliga som:

  • Produkter som du installerar på servern, som kallas egen värd.
  • Containrar körs i en värd som Docker.
  • Webbaserade tjänster som du integrerar med för att hantera identiteter.

Vissa lösningar är kostnadsfria och har öppen källkod, medan andra är kommersiellt licensierade. En lista över tillgängliga alternativ finns i lösningar för identitetshantering. Det är möjligt att din organisation redan använder en identitetsprovider. I så fall kan det vara klokt att använda den befintliga providern i stället för att gå med en annan lösning. Alla de viktigaste lösningarna innehåller dokumentation om hur du konfigurerar ASP.NET Core för att använda deras produkt eller tjänst.

Frånkopplade scenarier

Många lösningar, till exempel Microsoft Entra ID, är molnbaserade och kräver en Internetanslutning för att fungera. Om din miljö inte tillåter Internetanslutning kan du inte använda tjänsten.

ASP.NET Core Identity fungerar perfekt i frånkopplade scenarier, till exempel:

  • Appen kan inte komma åt Internet.
  • Appen måste fortfarande fungera i det lokala nätverket även om Internet är frånkopplat.

Om du behöver en fullständig OIDC-server för ett frånkopplat scenario väljer du något av följande alternativ:

  • En lösning som gör att du kan installera och köra tjänsten på dina egna datorer.
  • Kör autentiseringstjänsten lokalt som en container.

Bestämma var användardata som inloggningar lagras

En annan viktig faktor att tänka på är var användarens inloggningsdata lagras. Många utvecklare väljer externa, molnbaserade tjänster som Microsoft Entra-ID för att hantera identitet. En molnbaserad tjänstleverantör:

  • Tar på sig ansvaret att lagra data på ett säkert sätt.
  • håller programvaran uppdaterad med de senaste säkerhetskorrigeringarna och versionerna.
  • Följer sekretessreglerna.

Andra föredrar att lagra data på sina egna servrar på grund av regler, efterlevnad, princip eller andra orsaker.

Om data lagras på dina servrar måste du förmodligen välja en installationsbar eller containerbaserad lösning.

Identity jämfört med OIDC-server

Använd följande diagram för att avgöra om du vill använda ASP.NET Core Identity-systemet eller en OIDC-server för autentisering och auktorisering:

Identity hanteringsbeslutsflöde

I följande tabell visas några saker att tänka på när du väljer din identitetshanteringslösning.

Funktion egen värd (infrastruktur eller container) Cloud
Appintegreringen Lokala lösningar som implementeras som bibliotek eller ramverk kan ofta integreras direkt i din egen app. Containerbaserade lösningar kräver att en överlämning sker mellan webbappen och den containerbaserade tjänsten. Molnbaserade lösningar integreras vanligtvis på specifika platser i ditt inloggningsflöde och tillhandahåller konfiguration för att uppdatera användargränssnittet så att det matchar ditt tema, men anpassningsnivån är begränsad.
Konfiguration Självvärdslösningar kräver att programvaran konfigureras för miljön, samt att du ställer in hur du vill hantera identiteter. Containerbaserade lösningar tillhandahåller vanligtvis ett webbaserat användargränssnitt för konfiguration. Molnbaserade lösningar tillhandahåller vanligtvis ett webbaserat användargränssnitt för konfiguration.
Anpassning Lösningar för egen värd är vanligtvis mycket anpassningsbara, inklusive kodbaserade ändringar. Även om containerbaserade lösningar ger utökningsalternativ är de ofta mer begränsade. Molnbaserade tjänster tillåter anpassning, men det är vanligtvis begränsat till konfigurationsbaserade ändringar.
Underhåll Installerade produkter kräver en dedikerad resurs för att säkerställa att alla säkerhetskorrigeringar tillämpas i tid och för att hantera uppgraderingar. Uppgraderings- och korrigeringsprocessen för containrar är vanligtvis lägre friktion och innebär att du helt enkelt installerar den angivna containeravbildningen. Tjänstleverantören underhåller sin molnbaserade lösning, inklusive att tillämpa nödvändiga korrigeringar och hantera uppgraderingar.
Lagring av autentiseringsuppgifter för användare Du ansvarar för datastyrning och hantering av överträdelser. Hantera de risker som är kopplade till hantering av användarautentiseringsuppgifter och följa regler. delegeras till tjänstleverantören.

Mer information om tillgängliga alternativ finns i Identity hanteringslösningar för ASP.NET Core.

Nästa steg