An administrator receives a request from a developer: “Please give our reporting tool permission to read Microsoft 365 data.” The request sounds simple, yet it can represent several fundamentally different arrangements. Will a signed-in user approve a delegated permission, will a daemon run without a user, or will a multitenant application receive access in a customer’s tenant? The security implications depend on which identity acts and which resource accepts its token.
Microsoft SC-300 treats app registrations, API permissions, app roles, application authentication, enterprise applications, and consent as distinct parts of workload identity. A good implementation begins with the intended trust boundary, not with clicking “Grant admin consent” until a test passes.
Distinguish an application object from its tenant identity
The app registration defines the application’s identity configuration, including supported account types, client identifier, redirect URIs, credential settings, and API permissions being requested. A service principal represents a concrete instance of that application within a tenant. Microsoft’s application model describes the registration as the blueprint and the service principal as its local security identity.
In a single-tenant application, these concepts often appear together and are easy to blur. A multitenant app may have its registration in the publisher’s home tenant while customer tenants receive their own service principals through onboarding and consent. An administrator inspecting an enterprise app in the customer tenant is examining that local representation, not editing the publisher’s original registration.
This distinction matters when investigating a suspicious app. Removing a service principal or revoking its grants in one tenant is not the same as deleting the publisher’s app registration globally. Record the application ID, object ID, tenant, owner, verified publisher information, consent grants, and any associated credentials before deciding what should change.
Choose delegated scopes or app-only roles deliberately
Before recording API permissions, write the identity question in operational terms: will the API act for a signed-in user, or will a background app act as itself? For delegated access, test the intersection of the user’s own authorization and the granted scope; for application access, test the service’s allowed data set without any user session. Tenant-wide consent cannot stand in for data-level authorization implemented by the relying API.
Delegated permissions let an application act on behalf of a signed-in user, subject to the permission granted to the app and the user’s effective rights. Application permissions, commonly granted as app roles to a service principal, can allow unattended access without a user present. Granting a broadly powerful app-only permission is materially different from allowing a user-facing app to read only a user’s own information.
OAuth access tokens communicate claims to a resource API; they do not grant an abstract right to everything in a tenant. The resource must validate audience, issuer, expiry, and applicable scope or role claims. Different APIs have different permission models. An app that needs a narrow directory report should not receive a broad application permission simply because the developer found it easier to configure.
The vocabulary around OAuth, OpenID Connect, and SAML can help distinguish delegated authorization, user authentication, and federated single sign-on. A successful OIDC login does not prove that the app has an appropriate Graph API permission, and a Graph permission does not determine whether a separate SaaS application grants local access to data.
Make user and admin consent understandable
Consent records that a user or administrator authorized requested permissions under the organization’s policy. A consent prompt is not a license to assume every request is benign. Explain why each permission is necessary, whether it can read or modify data, whether it works without the user, and how users can report a suspicious request.
Some permissions require administrator approval; tenant consent policies can also limit what users may approve themselves. Review the permission’s actual scope and publisher before granting tenant-wide consent. A developer’s claim that an application is “internal” does not by itself establish trustworthy code, safe storage, or a valid business need.
Maintain a review route for requested application permissions. The requester supplies the API and workflow, the app owner explains why existing lower-privilege scopes do not work, security evaluates exposure, and an authorized administrator grants only the approved consent. This is preferable to giving developers permanent high-privilege administrator roles merely to bypass a blocked consent flow.
Secure redirects, certificates, and credentials
Redirect URIs are part of the application’s authentication trust. A permissive or stale redirect can direct authorization results toward the wrong receiver, so environment-specific URIs need deliberate registration and maintenance. Development callbacks and production callbacks should not be mixed casually; exact behavior depends on app type and identity-platform configuration.
For confidential clients, prefer credentials with clear ownership, expiration, rotation, and auditing; where supported, consider stronger asymmetric or workload federation approaches rather than long-lived client secrets. Public clients cannot keep embedded secrets confidential. A desktop or mobile app should use its intended public-client authentication pattern instead of pretending a packaged secret is private.
When an application runs on eligible Azure resources, managed identities for Azure workloads can eliminate many manually stored secrets. That is a distinct choice from registering an external app that uses a certificate or a federated identity credential. Authentication and authorization remain separate: obtaining a token is not equivalent to receiving a data-plane permission.
Test the full authorization path
An app registration’s ‘API permissions’ pane shows requested and granted permissions, but it does not establish that the relying API validates issuer, audience, expiration and the appropriate scp or roles claims for the route. Build tests for a delegated user without resource access, an app-only principal with narrower rights and an invalid token audience. Record which layer denies each request. These administrative configuration tests deliberately differ from the separate SC-500 threat-hunting work.
For a delegated reporting app, test with a normal user who has the smallest valid business access, then with a user who lacks it. Confirm that consent policy, application assignment, API scope, and resource authorization combine to produce the expected result. A successful admin sign-in is a poor substitute for testing the least-privileged intended user.
For a daemon, test access with no human user and a specific application permission. Verify that a token issued for one API cannot be treated as authorization by a different API, and confirm what audit events record the app’s access. Denials may arise from tenant policy, permission grants, service-principal state, or resource-specific role assignments; classify the failure before broadening permissions.
Where the application exposes app roles, define roles for actual business operations and keep default access narrow. A role named “Reader” needs a clear resource-side meaning. Document what a person or service principal can do with that role, who assigns it, and how the assignment will be reviewed.
Threat-model a multitenant publisher integration
A vendor offering a Microsoft 365 connector may publish one application registration in its home tenant, then ask each customer to consent to a local enterprise application. The customer’s decision should start with publisher authenticity, tenant restrictions, data required, requested API permissions and a process to revoke access. “Verified publisher” is a useful identity signal, not proof that every permission requested is necessary or safe.
Consider an integration that requests delegated access to calendars but also asks for broad mail permissions. Ask the vendor which workflow needs each scope, whether data is copied to vendor infrastructure, how tokens are stored, and whether granular permissions or an alternative integration are available. If the vendor needs an application permission rather than delegated access, determine exactly what unattended operation justifies persistent authority over multiple users’ data.
A malicious or overprivileged OAuth app can remain useful to an attacker without collecting the user’s password again. That is why consent phishing matters: a user might authorize an app that later reads permitted API data through valid tokens. The identity team needs visibility into new service principals, grants and consent activity as well as interactive sign-ins. Treat sudden increases in app data access as a reason to investigate, not as definitive proof of breach.
Application roles and groups create a separate boundary. An enterprise app may be limited to assigned users, but API permissions can permit data access independently for a daemon. Validate interactive sign-in policy and app-only permission grants as separate tests. A “user assignment required” setting does not turn every app-only API call into a user-bound request.
Before granting production consent, set a time for the first postdeployment review. Compare actual use to the requested scope, confirm the owner’s continuing need and remove test credentials or unused grants. A well-run consent process does not end at the approval click; it continuously narrows rights as the integration’s real behavior becomes visible.
Do not confuse redirect URI validation with access control to the application’s own business records. A correctly configured OAuth authorization flow proves that identity and token handling followed the protocol; the application’s code must still enforce per-user and per-resource authorization. An admin’s ability to configure consent also does not imply they should approve insecure software. Keep code security review, data protection and permission governance separate but mutually accountable.
Maintain an application inventory that can support an incident
An effective inventory identifies app owner, environment, registration tenant, local service principals, API permissions, consent status, credentials and expiry, and the data affected. Owners must be reachable after a developer changes teams; an orphaned high-privilege registration is an avoidable incident risk.
When a credential is compromised, responders need to know which credential or grant can be revoked without disabling unrelated services. Revoke compromised credentials and grants, rotate safely, inspect sign-ins and workload activity, and validate dependencies before restoring access. Avoid deleting a shared production enterprise app in panic if a targeted grant or secret revocation will address the exposure.
Good application registration governance means a future administrator can answer two questions quickly: what does this identity represent, and why can it access these resources? The answer belongs in durable ownership, consent, and permissions records—not in a one-time screenshot from the developer who originally requested access.