The Microsoft identity platform integration checklist is intended to guide you to a high-quality and secure integration. It highlights best practices and common oversights when integrating with the Microsoft identity platform so review the list on a regular basis to make sure you maintain the quality and security of your app’s integration with the identity platform. The checklist isn't intended to review your entire application. The contents of the checklist are subject to change as we make improvements to the platform.
If you’re just getting started, check out the documentation to learn about authentication basics, application scenarios in Microsoft identity platform, and more.
Provide a meaningful name and logo for your application. This information appears on your application’s consent prompt. Make sure your name and logo are representative of your company/product so that users can make informed decisions. Ensure that you're not violating any trademarks.
Provide links to your app's terms of service and privacy statement.
Maintain ownership of all your redirect URIs and keep the DNS records for them up-to-date. Don't use wildcards (*) in your URIs. For web apps, make sure all URIs are secure and encrypted (for example, using https schemes). For public clients, use platform-specific redirect URIs if applicable (mainly for iOS and Android). Otherwise, use redirect URIs with a high amount of randomness to prevent collisions when calling back to your app. If your app is being used from an isolated web agent, you may use https://login.microsoftonline.com/nativeclient. Review and trim all unused or unnecessary redirect URIs on a regular basis.
If your app is registered in a directory, minimize and manually monitor the list of app registration owners.
Protect and manage your app credentials. Use certificate credentials, not password credentials (client secrets). If you must use a password credential, don't set it manually. Don't store credentials in code or config, and never allow them to be handled by humans. If possible, use managed identities for Azure resources or Azure Key Vault to store and regularly rotate your credentials.
Make sure your application requests the least privilege permissions. Only ask for permissions that your application absolutely needs, and only when you need them. Understand the different types of permissions. Only use application permissions if required; use delegated permissions where possible. For a full list of Microsoft Graph permissions, see this permissions reference.
If you're securing an API using the Microsoft identity platform, carefully think through the permissions it should expose. Consider what's the right granularity for your solution and which permission(s) require admin consent. Check for expected permissions in the incoming tokens before making any authorization decisions.
Use modern authentication solutions (OAuth 2.0, OpenID Connect) to securely sign in users.
If the data your app requires is available through Microsoft Graph, request permissions for this data using the Microsoft Graph endpoint rather than the individual API.
Understand the consent experience and configure the pieces of your app’s consent prompt so that end users and admins have enough information to determine if they trust your app.
Minimize the number of times a user needs to enter login credentials while using your app by attempting silent authentication (silent token acquisition) before interactive flows.
Don't use “prompt=consent” for every sign-in. Only use prompt=consent if you’ve determined that you need to ask for consent for additional permissions (for example, if you’ve changed your app’s required permissions).
Where applicable, enrich your application with user data. Use the Microsoft Graph API is an easy way to do this. The Graph explorer tool that can help you get started.
Register the full set of permissions that your app requires so admins can grant consent easily to their tenant. Use incremental consent at run time to help users understand why your app is requesting permissions that may concern or confuse users when requested on first start.