Authentication
~3 mins read
Practically, the auth info provided is either
- something the user knows (like a password, PIN, or key)
- something the user has (like a smart card or proof of possession of a smart phone)
- something the user is (like the user’s fingerprint, voice, or face)
Keys are more general, passwords are more specific
For example a million users of a website can verify the site with a single certificate, while each user have their own password
Some auth good practices
Use 2-factor
Add exponential delay to repeated login attempts
Lock account after repeated failed login attempts
Use authorization levels.
Least privilege, never grant more access than required.
Separation of privileges, so your system is not all or nothing
Use allow-lists, not block-lists
MS auth
- Manage redirect URIs:
- Own and update DNS records
- Avoid wildcards in URIs
- Ensure HTTPS for web app URIs
- Use platform-specific or random URIs for public clients
- Utilize specific URI for isolated web agents
- Regularly review and remove unused URIs
- Directory app registration:
- Minimize and manually monitor owners
- OAuth2 implicit grant flow:
- Enable only when explicitly required
- Avoid resource owner password credential flow (ROPC):
- Use more secure authentication flows
- Consider specific scenarios like DevOps
- Protect confidential app credentials:
- Prefer certificate credentials over passwords
- Avoid manual setting of passwords
- Use Azure Key Vault or managed identities for storage and rotation
- Request least privilege permissions:
- Only request necessary permissions
- Understand application vs delegated permissions
- Secure API permissions
- Define permissions granularly
- Admin consent for critical permissions
- Validate expected permissions in tokens before authorization
- Use modern authentication solutions (OAuth 2.0, OpenID Connect) for user sign-ins.
- Leverage Microsoft Authentication Library (MSAL) instead of direct protocol programming.
- Do not parse or rely on access tokens in client applications; use ID tokens for user-related information.
- Migrate apps from Azure AD Authentication Library (ADAL) to MSAL for improved security and support.
- Configure mobile apps with broker redirect URIs for single sign-on using Microsoft Authenticator or Company Portal.
- Maintain one token cache per account in web apps and web APIs for efficient token management.
-
Request data permissions through Microsoft Graph endpoint for integrated data access.
- Understand and configure consent prompts to inform end users and admins adequately.
- Minimize user login prompts by using silent authentication wherever possible.
- Avoid using “prompt=consent” unnecessarily; use it only when additional permissions are required.
- Enrich application functionality with user data via Microsoft Graph API.
- Register all necessary permissions for easy admin consent and use incremental consent for user understanding.
- Implement a seamless single sign-out experience for privacy, security, and user satisfaction.