Best practices en aanbevelingen voor het Microsoft-identiteitsplatform

In dit artikel worden best practices, aanbevelingen en algemene toezichtspunten beschreven voor integratie met het Microsoft-identiteitsplatform. Deze controlelijst leidt u naar een hoogwaardige en veilige integratie. Bekijk deze lijst regelmatig om ervoor te zorgen dat u de kwaliteit en beveiliging van de integratie van uw app met het identiteitsplatform behoudt. De controlelijst is niet bedoeld om uw hele toepassing te controleren. De inhoud van de controlelijst kan worden gewijzigd wanneer we het platform verbeteren.

Als u net aan de slag gaat, raadpleegt u de documentatie van het Microsoft Identity Platform voor meer informatie over basisbeginselen van verificatie, toepassingsscenario's in het Microsoft Identity Platform en meer.

Gebruik de volgende controlelijst om ervoor te zorgen dat uw toepassing effectief is geïntegreerd met het Microsoft-identiteitsplatform.

Tip

De integratieassistent kan u helpen bij het toepassen van veel van deze aanbevolen procedures en aanbevelingen. Selecteer een van uw app-registraties en selecteer vervolgens het menu-item Integratieassistent om aan de slag te gaan met de assistent.

Basisprincipes

Lees en begrijp het Microsoft-platformbeleid. Zorg ervoor dat uw toepassing voldoet aan de voorwaarden die worden beschreven, aangezien deze zijn ontworpen om gebruikers en het platform te beschermen.

Eigendom

Zorg ervoor dat de informatie die is gekoppeld aan het account dat u hebt gebruikt voor het registreren en beheren van apps up-to-date is.

Branding

Voldoen aan de huisstijlrichtlijnen voor toepassingen.

Geef een betekenisvolle naam en logo op voor uw toepassing. Deze informatie wordt weergegeven in de toestemmingsprompt van uw toepassing. Zorg ervoor dat uw naam en logo representatief zijn voor uw bedrijf/product, zodat gebruikers weloverwogen beslissingen kunnen nemen. Zorg ervoor dat u geen handelsmerken schendt.

Privacy

Geef koppelingen op naar de servicevoorwaarden en privacyverklaring van uw app.

Beveiliging

Uw omleidings-URI's beheren:

• Behoud de rechten op al uw URI's voor omleiding en zorg ervoor dat de DNS-registraties actueel blijven.
• Gebruik geen jokertekens (*) in uw URI's.
• Voor web-apps moet u ervoor zorgen dat alle URI's veilig en versleuteld zijn (bijvoorbeeld met https-schema's).
• Gebruik voor openbare clients platformspecifieke URI's voor omleiding indien van toepassing (voornamelijk voor iOS en Android). Gebruik anders URI's voor omleiding met een grote hoeveelheid willekeurigheid om conflicten te voorkomen bij het opnieuw aanroepen van uw app.
• Als uw app wordt gebruikt vanuit een geïsoleerde webagent, kunt u https://login.microsoftonline.com/common/oauth2/nativeclient gebruiken.
• Controleer en kort alle ongebruikte of onnodige URI's voor omleiding regelmatig in.

Als uw app is geregistreerd in een directory, minimaliseert u de lijst met app-registratie-eigenaren en bewaakt u deze handmatig.

Schakel geen ondersteuning in voor de impliciete OAuth2-toekenningsstroom , tenzij dit expliciet is vereist. Meer informatie over het geldige scenario vindt u hier.

Ga verder dan gebruikersnaam/wachtwoord. Gebruik geen wachtwoordstroom voor de resource-eigenaar (ROPC), waarmee de wachtwoorden van gebruikers rechtstreeks worden verwerkt. Deze stroom vereist een hoge mate van vertrouwen en blootstelling van gebruikers en mag alleen worden gebruikt wanneer andere, veiligere stromen niet kunnen worden gebruikt. Deze stroom is nog steeds nodig in sommige scenario's (zoals DevOps), maar wees ervan bewust dat het gebruik hiervan uw toepassing beperkingen zal opleggen. Lees verificatiestromen en toepassingsscenario's voor modernere benaderingen.

Bescherm en beheer uw vertrouwelijke app-referenties voor web-apps, web-API's en daemon-apps. Gebruik certificaatreferenties in plaats van wachtwoordreferenties (clientgeheimen). Als u een wachtwoordreferentie moet gebruiken, moet u deze niet handmatig instellen. Sla geen referenties op in code of configuratie en sta nooit toe dat ze door personen worden verwerkt. Gebruik indien mogelijk beheerde identiteiten voor Azure-bronnen of Azure Key Vault om uw referenties op te slaan en regelmatig te roteren.

Zorg ervoor dat uw toepassing de machtigingen voor minimale bevoegdheden aanvraagt. Vraag alleen om machtigingen die uw toepassing absoluut nodig heeft en alleen wanneer u deze nodig hebt. Inzicht in de verschillende typen machtigingen. Gebruik zo nodig alleen toepassingsmachtigingen; gebruik waar mogelijk gedelegeerde machtigingen. Bekijk deze naslaginformatie over machtigingen voor een volledige lijst met Microsoft Graph-machtigingen.

Als u een API beveiligt met behulp van het Microsoft Identity Platform, moet u zorgvuldig nadenken over de machtigingen die de API beschikbaar moet maken. Bedenk wat de juiste granulariteit is voor uw oplossing en welke machtigingen beheerderstoestemming vereisen. Controleer op verwachte machtigingen in de binnenkomende tokens voordat u autorisatiebeslissingen neemt.

Implementatie

Gebruik moderne verificatieoplossingen (OAuth 2.0, OpenID Verbinding maken) om gebruikers veilig aan te melden.

Programma niet rechtstreeks op protocollen zoals OAuth 2.0 en Open ID. Stem in plaats daarvan de MSAL (Microsoft Authentication Library) af. De MSAL-bibliotheken verpakken beveiligingsprotocollen veilig in een gebruiksvriendelijke bibliotheek. En u krijgt ingebouwde ondersteuning voor scenario's voor voorwaardelijke toegang, apparaatbrede eenmalige aanmelding (SSO) en ingebouwde ondersteuning voor het in de cache opslaan van tokens. Bekijk de lijst met door Microsoft ondersteunde clientbibliotheken voor meer informatie. Als u handmatig moet coderen voor de verificatieprotocollen, moet u de Microsoft SDL of een vergelijkbare ontwikkelingsmethodologie volgen. Let goed op de beveiligingsoverwegingen in de standaardenspecificaties voor elk protocol.

Migreer bestaande apps van Azure Active Directory Authentication Library (ADAL) naar de Microsoft Authentication Library. MSAL is de nieuwste identiteitsplatformoplossing van Microsoft en is beschikbaar op .NET, JavaScript, Android, iOS, macOS, Python en Java. Lees meer over het migreren van ADAL.NET-, ADAL.js- en ADAL.NET- en iOS-broker-apps.

Voor mobiele apps configureert u elk platform met behulp van de toepassingsregistratie-ervaring. Om te kunnen profiteren van de Microsoft Authenticator of Microsoft Bedrijfsportal voor eenmalige aanmelding, heeft uw app een 'broker redirect URI' geconfigureerd. Hierdoor kan Microsoft na verificatie de controle teruggeven aan uw toepassing. Bij het configureren van elk platform leidt de app-registratie u door het proces. Gebruik de quickstart om een werkend voorbeeld te downloaden. Gebruik in iOS waar mogelijk webweergave voor brokers en systeem.

Houd in web-apps of web-API's één tokencache per account. Voor web-apps moet de token-cache worden gesleuteld door de account-id. Voor web-API's moet het account worden gesleuteld door de hash van het token dat wordt gebruikt om de API aan te roepen. MSAL.NET biedt aangepaste serialisatie van tokencaches in zowel .NET als .NET Framework. Voor de veiligheid en prestaties wordt aanbevolen één cache per gebruiker te serialiseren. Lees voor meer informatie over serialisatie van token-caches.

Als de gegevens die uw app nodig heeft, beschikbaar zijn via Microsoft Graph, vraagt u machtigingen voor deze gegevens aan met behulp van het Microsoft Graph-eindpunt in plaats van de afzonderlijke API.

Bekijk de waarde van het toegangstoken niet of probeer deze te parseren als een client. Ze kunnen waarden en indelingen wijzigen of zelfs zonder waarschuwing worden versleuteld. Gebruik altijd de id_token als uw client iets over de gebruiker moet weten of Microsoft Graph moet aanroepen. Alleen web-API's moeten toegangstokens parseren (omdat ze de indeling definiëren en de versleutelingssleutels instellen).

Ervaring voor de eindgebruiker

Begrijp de toestemmingservaring en configureer de onderdelen van de toestemmingsprompt van uw app, zodat eindgebruikers en beheerders voldoende informatie hebben om te bepalen of ze uw app vertrouwen.

Minimaliseer het aantal keren dat een gebruiker aanmeldingsreferenties moet invoeren tijdens het gebruik van uw app door stille verificatie uit te voeren (stille tokenverwerving) vóór interactieve stromen.

Gebruik 'prompt=consent' niet voor elke aanmelding. Gebruik alleen prompt=consent als u hebt vastgesteld dat u om toestemming moet vragen voor aanvullende machtigingen (bijvoorbeeld als u de vereiste machtigingen van uw app hebt gewijzigd).

Verrijk uw toepassing indien van toepassing met gebruikersgegevens. Het gebruik van de Microsoft Graph API is een eenvoudige manier om dit te doen. Het hulpprogramma Graph Explorer waarmee u aan de slag kunt gaan.

Registreer de volledige set machtigingen die uw app nodig heeft, zodat beheerders eenvoudig toestemming kunnen verlenen aan hun tenant. Gebruik incrementele toestemming tijdens uitvoeringstijd om gebruikers te helpen begrijpen waarom uw app machtigingen aanvraagt die mogelijk betrekking hebben op of verwarrend zijn voor gebruikers wanneer ze worden aangevraagd bij het eerste begin.

Implementeer een schone ervaring voor eenmalige afmelding. Het is een privacy- en beveiligingsvereiste en zorgt voor een goede gebruikerservaring.

Testen

Test op beleid voor voorwaardelijke toegang dat van invloed kan zijn op de mogelijkheid van uw gebruikers om uw toepassing te gebruiken.

Test uw toepassing met alle mogelijke accounts die u wilt ondersteunen (bijvoorbeeld werk- of schoolaccounts, persoonlijke Microsoft-accounts, onderliggende accounts en soevereine accounts).

Aanvullende bronnen

Gedetailleerde informatie over v2.0 verkennen:

• Microsoft-identiteitsplatform (overzicht)
• Naslaginformatie voor protocollen voor het Microsoft-identiteitsplatform
• Naslaginformatie voor Access-tokens
• Naslaginformatie voor id-tokens
• Naslaginformatie over verificatiebibliotheken
• Machtigingen en toestemming op het Microsoft Identity Platform
• Microsoft Graph API