Every "Sign in with Microsoft" Button Is a Data Grant

Procurement knows what was purchased. Entra knows what was connected. The two lists rarely match, and the difference is the part nobody reviewed. When an employee clicks “Sign in with Microsoft” on a new web tool, they are not just authenticating. They are installing a third-party application into the tenant and issuing it a credential. The button is the front door, but the consequential moment is the consent request for permissions. Users think they are bypassing a registration form. The directory knows they are granting persistent access to corporate data.

A canceled subscription is not a revoked grant. The trial ends in the SaaS vendor’s billing system, not in Microsoft Entra ID. The user stops opening the app, but the OAuth grant remains. The consent screen renders a line that reads “Maintain access to data you have given it access to.” That is the euphemism for a refresh token. It issues a token that renews as long as the app keeps using it. The grant outlives the browser tab, the five-day trial, the employee, and usually the contract.

The consent screen itself is a contract written by the vendor and signed with a click. The permission names belong to Microsoft, but the descriptions belong to the vendor. Users treat the prompt like an end-user license agreement. They click Accept because they have ten minutes to build a schedule.

Run the grant inventory for the first time and you get a list of apps the security team has never seen. The export is thousands of rows long. It includes dozens of PDF converters, AI meeting transcription bots with calendar access to the executive team, and flashcard apps from five years ago that no longer exist on the public internet but still hold an active token.

Most one-shot audits run a single query against Microsoft Graph and declare the tenant clean. That misses the rest of the environment. Microsoft Graph, Office 365 Exchange Online, SharePoint Online, and legacy AAD Graph are separate resources with separate grants. An Outlook add-in might request Exchange Online permissions and never appear in a Graph-only query.

The data exposure depends on the permission type. Delegated permissions act on behalf of the user. Application permissions act as the app with no user at all. Mail.Read as a delegated permission reads one mailbox. Mail.Read as an application permission reads every mailbox in the tenant. Application permissions require admin consent, which means someone in the tenant explicitly granted them.

After a phishing incident, security teams often lock down user consent. They write a policy and run an awareness campaign. The setting is not retroactive. The grants from before the lockdown are still live, still renewing, and still holding access. Policy is forward-looking; inventories are backward-looking. Most organizations do one and assume they have done both.

Admin consent scales the risk. It turns one person’s trial into a tenant-wide decision. The OAuth permission grant object has a consent type. AllPrincipals means an admin consented on behalf of everyone. Deleting the user who requested it does not remove an AllPrincipals grant, because the user was never the principal holding the access.

Turning on the admin consent workflow to stop users from self-serving forces IT to arbitrate which productivity tools the business is allowed to use. An infrastructure team once flipped the switch and blocked users from granting permissions to unapproved apps. By 10:00 AM, the service desk had 400 tickets. Marketing could not use a webinar polling tool, and finance was locked out of a tax calculator. The policy was rolled back by noon.

The offboarding ticket closes when the account is disabled, the mailbox is converted to shared, and the laptop is returned. The third-party apps the user consented to are not on the ticket. Disabling the account does not touch the delegated grant records.

The app registration has an owner field, but it is a ghost field. The owner is often a disabled account belonging to a departed employee. The client secret expires next quarter, and the calendar reminder goes to a mailbox nobody reads. During a tenant-to-tenant migration, an integration team dumps the enterprise applications list and finds rows named “Test App” and “Graph Integration.” Both hold directory read access as an application permission. Neither has an owner who works there.

You cannot mass-revoke without breaking undocumented business processes. Deleting a service principal outright can break an integration that runs on a schedule. The safe sequence is to disable the application, watch the sign-in logs for a week, and then delete it. But if user consent is still allowed, the app can be re-consented the next time someone clicks the button. Revoking refresh tokens invalidates sessions, but the grant record remains.

The SaaS inventory the business bought a cloud security broker to build already exists natively in the directory. The service principal is the only artifact of a vendor relationship that never went through procurement. If you cannot name the applications that can read every mailbox in your tenant, you do not have an inventory. You have a list of purchases.