Microsoft platforma za identitete bästa praxis och rekommendationer
Den här artikeln beskriver metodtips, rekommendationer och vanliga tillsyner när du integrerar med Microsoft platforma za identitete. Den här checklistan vägleder dig till en högkvalitativ och säker integrering. Granska den här listan regelbundet för att se till att du upprätthåller kvaliteten och säkerheten för appens integrering med identitetsplattformen. Checklistan är inte avsedd att granska hela programmet. Innehållet i checklistan kan komma att ändras när vi gör förbättringar av plattformen.
Om du precis har börjat kan du läsa dokumentationen om Microsoft platforma za identitete för att lära dig mer om grunderna för autentisering, programscenarier i Microsoft platforma za identitete med mera.
Använd följande checklista för att säkerställa att programmet är effektivt integrerat med Microsoft platforma za identitete.
Dricks
Integrationsassistenten kan hjälpa dig att tillämpa många av dessa metodtips och rekommendationer. Välj någon av dina appregistreringar och välj sedan menyalternativet Integration Assistant för att komma igång med assistenten.
Grundläggande
Läs och förstå Microsofts plattformsprinciper. Se till att ditt program följer de villkor som beskrivs när de är utformade för att skydda användare och plattformen.
Ägarskap
Kontrollera att informationen som är kopplad till det konto som du använde för att registrera och hantera appar är uppdaterad.
Profilering
Följ riktlinjerna för varumärkesanpassning för program.
Ange ett beskrivande namn och en logotyp för ditt program. Den här informationen visas i programmets medgivandeprompt. Kontrollera att ditt namn och din logotyp är representativa för ditt företag/din produkt så att användarna kan fatta välgrundade beslut. Se till att du inte bryter mot några varumärken.
Sekretess
Ange länkar till appens användarvillkor och sekretesspolicy.
Säkerhet
Hantera dina omdirigerings-URI:er:
- Behåll ägarskapet för alla dina omdirigerings-URI:er och håll DNS-posterna uppdaterade.
- Använd inte jokertecken (*) i dina URI:er.
- För webbappar kontrollerar du att alla URI:er är säkra och krypterade (till exempel med hjälp av https-scheman).
- För offentliga klienter använder du plattformsspecifika omdirigerings-URI:er om tillämpligt (främst för iOS och Android). Annars kan du använda omdirigerings-URI:er med hög slumpmässighet för att förhindra kollisioner när du anropar tillbaka till din app.
- Om din app används från en isolerad webbagent kan du använda
https://login.microsoftonline.com/common/oauth2/nativeclient. - Granska och trimma alla oanvända eller onödiga omdirigerings-URI:er regelbundet.
Om din app är registrerad i en katalog ska du minimera och manuellt övervaka listan över appregistreringsägare.
Aktivera inte stöd för det implicita OAuth2-beviljandeflödet om det inte uttryckligen krävs. Läs mer om det giltiga scenariot här.
Gå längre än användarnamn/lösenord. Använd inte resursägarens flöde för lösenordsautentiseringsuppgifter (ROPC), som direkt hanterar användarnas lösenord. Det här flödet kräver en hög grad av förtroende och användarexponering och bör endast användas när andra, säkrare flöden inte kan användas. Det här flödet behövs fortfarande i vissa scenarier (till exempel DevOps), men se upp för att användningen av det medför begränsningar för ditt program. Mer moderna metoder finns i Autentiseringsflöden och programscenarier.
Skydda och hantera dina autentiseringsuppgifter för konfidentiella appar för webbappar, webb-API:er och daemonappar. Använd certifikatautentiseringsuppgifter, inte autentiseringsuppgifter för lösenord (klienthemligheter). Om du måste använda en lösenordsautentiseringsuppgift ska du inte ange den manuellt. Lagra inte autentiseringsuppgifter i kod eller konfiguration och låt dem aldrig hanteras av människor. Använd om möjligt hanterade identiteter för Azure-resurser eller Azure Key Vault för att lagra och regelbundet rotera dina autentiseringsuppgifter.
Kontrollera att programmet begär minst behörigheter. Be bara om behörigheter som ditt program absolut behöver, och bara när du behöver dem. Förstå de olika typerna av behörigheter. Använd endast programbehörigheter om det behövs. använd delegerade behörigheter där det är möjligt. En fullständig lista över Microsoft Graph-behörigheter finns i den här behörighetsreferensen.
Om du skyddar ett API med hjälp av Microsoft platforma za identitete bör du noggrant tänka igenom de behörigheter som ska exponeras. Tänk på vad som är rätt kornighet för din lösning och vilka behörigheter som kräver administratörsmedgivande. Kontrollera om det finns förväntade behörigheter i inkommande token innan du fattar några auktoriseringsbeslut.
Implementering
Använd moderna autentiseringslösningar (OAuth 2.0, OpenID Connect) för att logga in användare på ett säkert sätt.
Programmera inte direkt mot protokoll som OAuth 2.0 och Open ID. Använd i stället Microsoft Authentication Library (MSAL). MSAL-biblioteken omsluter säkerhetsprotokoll på ett säkert sätt i ett lättanvänt bibliotek, och du får inbyggt stöd för scenarier med villkorsstyrd åtkomst, enkel inloggning på hela enheten (SSO) och inbyggt stöd för cachelagring av token. Mer information finns i listan över Klientbibliotek som stöds av Microsoft. Om du måste handkoda för autentiseringsprotokollen bör du följa Microsoft SDL eller liknande utvecklingsmetodik. Var noga med säkerhetsövervägandena i standardspecifikationerna för varje protokoll.
Titta INTE på värdet för åtkomsttoken eller försök parsa det som en klient. De kan ändra värden, format eller till och med krypteras utan varning – använd alltid ID-token om klienten behöver lära sig något om användaren. Endast webb-API:er ska parsa åtkomsttoken (eftersom det är de som definierar formatet och anger krypteringsnycklarna). Att skicka en åtkomsttoken direkt till ett API av klienten är en säkerhetsrisk, eftersom det är känsliga autentiseringsuppgifter som ger åtkomst till vissa resurser. Utvecklare bör inte anta att klienten kan vara betrodd för att verifiera åtkomsttoken.
Migrera befintliga appar från Azure Active Directory Authentication Library (ADAL) till Microsoft Authentication Library. MSAL är Microsofts senaste lösning för identitetsplattform och är tillgänglig på .NET, JavaScript, Android, iOS, macOS, Python och Java. Läs mer om att migrera ADAL.NET, ADAL.js och ADAL.NET- och iOS-koordinatorappar .
För mobilappar konfigurerar du varje plattform med hjälp av programregistreringsupplevelsen. För att ditt program ska kunna dra nytta av Microsoft Authenticator eller Microsoft-företagsportalen för enkel inloggning behöver din app en konfigurerad "broker redirect URI". På så sätt kan Microsoft returnera kontroll till ditt program efter autentisering. När du konfigurerar varje plattform vägleder appregistreringen dig genom processen. Använd snabbstarten för att ladda ned ett fungerande exempel. I iOS använder du asynkrona koordinatorer och systemwebbvyer när det är möjligt.
Behåll en tokencache per konto i webbappar eller webb-API:er. För webbappar ska tokencachen vara nyckelad av konto-ID:t. För webb-API:er ska kontot nyckelas av hashen för den token som används för att anropa API:et. MSAL.NET tillhandahåller anpassad tokencache-serialisering i både .NET och .NET Framework. Av säkerhetsskäl och prestandaskäl rekommenderar vi att du serialiserar en cache per användare. Mer information finns i om tokencache-serialisering.
Om de data som din app kräver är tillgängliga via Microsoft Graph begär du behörigheter för dessa data med hjälp av Microsoft Graph-slutpunkten i stället för det enskilda API:et.
Slutanvändarens upplevelse
Förstå medgivandeupplevelsen och konfigurera delarna i appens medgivandeprompt så att slutanvändare och administratörer har tillräckligt med information för att avgöra om de litar på din app.
Minimera antalet gånger en användare behöver ange inloggningsuppgifter när du använder din app genom att försöka använda tyst autentisering (tyst tokenförvärv) före interaktiva flöden.
Använd inte "prompt=consent" för varje inloggning. Använd endast prompt=consent om du har fastställt att du behöver be om medgivande för ytterligare behörigheter (till exempel om du har ändrat appens nödvändiga behörigheter).
När det är tillämpligt utökar du ditt program med användardata. Att använda Microsoft Graph API är ett enkelt sätt att göra detta. Graph Explorer-verktyget som kan hjälpa dig att komma igång.
Registrera den fullständiga uppsättning behörigheter som din app kräver så att administratörer enkelt kan bevilja medgivande till sin klientorganisation. Använd inkrementellt medgivande vid körning för att hjälpa användarna att förstå varför din app begär behörigheter som kan oroa eller förvirra användare när de begärs vid första start.
Implementera en ren enkel utloggning. Det är en sekretess och ett säkerhetskrav och ger en bra användarupplevelse.
Testning
Testa principer för villkorsstyrd åtkomst som kan påverka användarnas möjlighet att använda ditt program.
Testa ditt program med alla möjliga konton som du planerar att stödja (till exempel arbets- eller skolkonton, personliga Microsoft-konton, underordnade konton och nationella konton).
Ytterligare resurser
Utforska detaljerad information om v2.0: