Skip to main content

​
How Amnify authenticates

Amnify is a single multi-tenant Microsoft Entra application. When you connect Azure, you authorize it once, which provisions a service principal (an “enterprise application”) in your tenant. Amnify then authenticates as the application, using its own confidential client secret, to read posture data. It stores no user passwords and no customer secrets. The authorization request asks only for the minimal OpenID Connect scopes: openid, profile, and email. These low-impact, user-consentable permissions identify the tenant and establish the application in the directory. On their own they grant no access to resources or directory data. Where an organization restricts application consent, Microsoft routes the request to that organization’s own administrator, who approves it in the Azure portal without needing an Amnify account. Resource access is granted separately, as an Azure role assignment, not through OAuth consent.

Connect Azure — user consent (no optional permissions)

Sign in and consent to the minimal openid, profile, and email scopes only. This establishes the Amnify application in your tenant without any optional directory permissions and can be completed by a standard user.

​
Steps to connect

1

Consent to the Amnify application

Sign in and consent using the card above. This provisions the Amnify service principal (enterprise application) in your tenant and requests only openid, profile, and email. A standard user can complete it; where your tenant restricts consent, an administrator approves it.
2

Assign the Reader role to the application

In the Azure portal, assign the built-in Reader role to the Amnify application at each subscription you want assessed, or at a management group to cover many at once — plus the small custom role for the two app-service read actions. See Tier 1.
3

(Optional) Grant Entra ID directory read access

To assess the identity layer, a tenant administrator grants admin consent for the three read-only Microsoft Graph permissions using the card in Tier 2. You can add this later without disrupting existing scans.

​
Tier 1: Subscription read access (required)

What: the subscription permission is the built-in Reader role (Azure RBAC), assigned to the Amnify application at either:
  • each subscription you want assessed, or
  • a management group, to cover many subscriptions at once.
Plus a small custom role for two read actions that Reader omits:
  • Microsoft.Web/sites/host/listkeys/action
  • Microsoft.Web/sites/config/list/Action
Why: Posture assessment inspects how your resources are configured (networking, storage, compute, databases, key vaults, and resource-level identity assignments) to flag insecure settings. Reader grants read-only visibility into that configuration and nothing more. It cannot change, create, or delete resources, and it cannot read the data inside them, such as blob contents, database rows, or secret values. The two extra read actions serve a handful of app-service checks that must read app-service configuration and host-key metadata to confirm secure settings. Reader excludes those reads, so a minimal custom role adds them at the same scope as Reader. This tier alone enables the full set of subscription and resource posture checks. It is purely an Azure role assignment on your side, and it needs no Microsoft Graph permission and no directory-wide consent.

​
Tier 2: Microsoft Entra ID directory access (optional)

What: three admin-consented Microsoft Graph application permissions:
  • Directory.Read.All: read directory objects (users, groups, roles, service principals, and organization settings).
  • Policy.Read.All: read directory policies (Conditional Access, authorization, consent, and security-defaults).
  • UserAuthenticationMethod.Read.All: read which authentication methods users have registered. Used only for multi-factor-authentication posture.
Why: This tier assesses the identity layer itself: privileged role assignments, Conditional Access coverage, legacy-auth exposure, and MFA registration. It reads identity configuration only. It cannot read mailbox or file content, and it cannot reset credentials or change anything. Why it is optional and separate: None of this is needed to assess subscription resources. This step goes through admin consent because most organizations require a Global Administrator or Application Administrator to approve any consent an enterprise application is granted — so Microsoft routes the request to your tenant’s administrator, who approves it in the Azure portal without needing an Amnify account. These are also application permissions, which additionally require administrator consent under Microsoft’s rules, but the organization’s consent policy is the primary reason an administrator — rather than a standard user — completes this step. You can add them later, after Tier 1 is working, without disrupting existing scans.

Grant admin consent — with optional permissions

A tenant administrator grants tenant-wide admin consent for the optional Microsoft Graph application permissions listed above. Requires an administrator — a standard user cannot complete this flow.
Least-privilege notes:
  • All three are read-only.
  • Amnify requests Directory.Read.All rather than narrower per-object permissions because the identity checks span users, groups, roles, and service principals together. It deliberately does not request the broader “read all users’ full profiles” permission (User.Read.All), which is unnecessary and redundant with Directory.Read.All.
What Amnify never asks for on Azure
  • No write or modify Azure RBAC permissions, only Reader plus the two read actions above.
  • No Microsoft Graph write permissions.
  • No access to mailboxes, files, Teams, or any message or content data.
  • No long-lived customer secrets. You grant a role assignment (Tier 1) and, optionally, admin consent (Tier 2). You never paste credentials into Amnify.