TECHNICAL REFERENCE

How MSPs should read OAuth permission evidence.

An OAuth audit should review permission type, scope, consent, publisher context, ownership, assignments, activity, credentials, and business purpose together. A single permission name rarely tells the full story.

What is the difference between delegated and application permissions?

Delegated permissions let an application act within the signed-in user and granted scope. Application permissions let a service act without a signed-in user and can reach organization-wide data or operations. Risk depends on the exact permission, consent type, application design, owner, use, credentials, and compensating controls.

Evidence to reviewQuestion it should answer

Permission type and scopeWhat could the application do, and under whose authority?

Consent type and dateWas access granted by a user or administrator, and is it still justified?

Publisher verificationWhat identity assurance is available, and what does it not guarantee?

Owners and business purposeWho can defend the need and approve lifecycle decisions?

Assignments and activityWho may use it, and what supported evidence shows recent use?

Credentials and expiryWhich secrets or certificates sustain access, and who rotates them?

Change historyDid permissions, consent, credentials, or ownership change over time?

Installed does not mean used. No activity evidence does not always mean unused.

Record which source was read, its time window, its permission and license requirements, and whether the result is observed, partial, unknown, or unreadable.

See the application-governance workflow →

SCOUTz OPEN BETA

Point SCOUTz at the question. Walk in with a defensible answer.

Bring a real MSP workflow and see how SCOUTz turns evidence into the next defensible action. The review runs without an agent or install and never changes configuration automatically.

SCOUTz prepares the conversation. The relationship and the sale stay yours.

Join Open Beta Run a score now · no signup