Building secure applications using modern authentication (part 2)

This post is a part of a series.

• Part 1 – The basics
• Part 2 – About scopes or permissions and MSAL (this post)
• Part 3 – App Gallery and publisher verification
• Part 4 – Additional Security Features

Azure Active Directory, which is the Identity Provider (IdP) or OpenID Provider (OP) behind Azure and Office 365, supports OpenID Connect (OIDC) and OAuth 2.0, for authentication and authorization, respectively. It does this via Application Registrations and Service Principals (Enterprise Applications), which in turn are assigned permissions (scopes) for a variety of APIs, including Microsoft Graph API, as well as custom APIs exposed by applications on AAD. 

OAuth and OIDC are supported for both applications and services where AAD is the IdP/OP as well as within the AAD tenant itself and it works in the same manner.  I state this because unfortunately, that’s not the case for all IdPs. Some IdPs support OAuth for registered applications, but not for tenant/organization level access, such as unlocking a user or resetting MFA, etc.

Azure AD offers different types of permissions (scopes) for the various flows, as described on part 1 of this series. As we talk about permissions, please keep in mind that organizations can determine how and who can consent to the various permissions by updating the tenant settings. More about this in part 3 of the series.

There are different types of permissions mostly because they are meant for different types of applications and processes. Here is a quick summary of the types of permissions, their intended use, the consent required, and the effective permissions.

Interactive Application (signed-in user)

For interactive applications where a signed-in user is logged in, the applications will get access on behalf of users, which is the case for mobile, web, or SPAs (Single Page Applications). These interactive applications should be using delegated permissions since they act as the signed-in user when making calls to the API.

By default users can consent to delegated permissions, however admins will have to consent to some higher privileged permissions and when the permissions are required for all users. Consent is usually requested automatically when the user initially accesses an application that requires permissions that are protected by OAuth, or if the application specifically requests consent. It can also happen if the permissions have changed, if the user or an admin revoked the consent, or if the application is using incremental consent to ask for some permissions now and more later as needed, maybe for optional features. Incremental consent is a great way to abide by the principle of least privilege.

The effective permissions of interactive applications are essentially the intersection of the delegated permissions assigned to the application and the permissions the user has been granted within the system, which essentially prevents elevation of privilege.

Background Service or Daemon Process

For background services or daemon processes, the applications can only log in as themselves or a Service Principal (SPN).  Only administrators can consent to application permissions, since there is no associated user. These applications will require application permissions since there is no signed-in user and they make calls to the API as the SPN with the associated credentials, which can be a secret or a certificate.  These credentials should be stored in a password vault, such as Azure Key Vault. The great thing about using AKV is that you can use a managed identity to access the vault where the secret is kept, only when needed. Internally, managed identities are service principals that can be locked to only be used with specific Azure resources. Additionally, there are no credentials in the code, Azure takes care of rolling the credentials that are used. When the managed identity is deleted, the corresponding service principal is automatically removed. Permissions for MSIs are assigned via PowerShell (New-AzureADServiceAppRoleAssignment) or CLI, not the portal.

The effective permissions of these applications are the full application permissions that were granted and consented to for this application, since there is no associated user signed-in.

NOTE: Granting application permissions to interactive applications can significantly increase the risk associated due to the possibility of inadvertently elevating privileges for a signed-in user that can circumvent any permission guardrails directly associated with the user. For example, the Mail.Read permission, when assigned as a delegated permission “Allows the app to read the signed-in user’s mailbox“, but when assigned as an application permission, it “Allows the app to read mail in all mailboxes without a signed-in user“.

The permissions referenced above are assigned via the Application Registration menu, within the API permissions blade:

Even Exchange?

And in case you are wondering, yes, even accessing mail endpoints can be accomplished using OAuth, for additional details, please reference the links below:

• Microsoft Graph Outlook API for mail, calendars, and contacts
• Authenticate an IMAP, POP or SMTP connection using OAuth

MSAL

One of the best benefits AAD offers is MSAL. The Microsoft Authentication Library (MSAL) is a set of libraries that authenticate and authorize users and applications. They are OAuth 2.0 and OIDC connect libraries that are built to handle protocol level details for developers. They stay up to date with the latest security updates and cache and refresh tokens automatically so developers don’t have to worry about the token expiration within custom applications. Basically, it provides developers a safe head start with OAuth 2.0 and OIDC for custom applications.

MSAL supports CAE (Continuous Access Evaluation), which is a new feature that allows tokens to be revoked as needed, based on specific risks, events (i.e. user is disabled), or policy updates (new location), etc. This feature allows tokens to have a longer life because they can be revoked when there is an action that dictates the access must be removed. MSAL supports this feature and will proactively refresh the tokens as needed. So, not only is your application safer, but it’s also more efficient.

MSAL also supports PIM and Conditional Access, including authentication context, which allows you to protect specific sensitive resources within your custom application. For an example of how Conditional Access works, please reference my previous blogs (Restrict downloads for sensitive (confidential) documents to only compliant devices and Passwordless Azure VM SSH login using FIDO2 security keys).

In part 3 of the series I’ll cover the App Gallery and the concept of publisher verification.