This article highlights best practices, recommendations, and common oversights when integrating with the Microsoft identity platform. This checklist will guide you to a high-quality and secure integration. Review this 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.
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.
Manage your redirect URIs:
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.
Move beyond username/password. Don't use resource owner password credential flow (ROPC), which directly handles users’ passwords. This flow requires a high degree of trust and user exposure and should only be used when other, more secure, flows can't be used. This flow is still needed in some scenarios (like DevOps), but beware that using it will impose constraints on your application. For more modern approaches, read Authentication flows and application scenarios.
Protect and manage your confidential app credentials for web apps, web APIs and daemon apps. 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 necessary; 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 you must hand code for the authentication protocols, you should follow a methodology such as Microsoft SDL. Pay close attention to the security considerations in the standards specifications for each protocol.
For mobile apps, configure each platform using the application registration experience. In order for your application to take advantage of the Microsoft Authenticator or Microsoft Company Portal for single sign-in, your app needs a “broker redirect URI” configured. This allows Microsoft to return control to your application after authentication. When configuring each platform, the app registration experience will guide you through the process. Use the quickstart to download a working example. On iOS, use brokers and system webview whenever possible.
In web apps or web APIs, keep one token cache per account. For web apps, the token cache should be keyed by the account ID. For web APIs, the account should be keyed by the hash of the token used to call the API. MSAL.NET provides custom token cache serialization in the .NET Framework and .NET Core subplatforms. For security and performance reasons, our recommendation is to serialize one cache per user. For more information, read about token cache serialization.
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.
Don't look at the access token value, or attempt to parse it as a client. They can change values, formats, or even become encrypted without warning - always use the id_token if your client needs to learn something about the user, or call Microsoft Graph. Only web APIs should parse access tokens (since they are the ones defining the format and setting the encryption keys).
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. Using 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.