Azure status integration: Service Principal vs. OAuth

Why choose service principal?

It’s not tied to an individual. An OAuth connection is tied to whoever signed in. When that person leaves, has their account disabled, or simply has their Azure role narrowed, the connection stops working and you could miss Azure outage alerts. A service principal has no person behind and therefore doesn’t suffer from this problem.

Nothing of ours gets installed in your tenant. OAuth requires your directory to consent to the StatusGator application for Azure Service Management access. In plenty of organizations that’s a review process which can take a while. The service principal path is easier – you create the service principal, assign it access to subscriptions or management groups you want to monitor.

You control the scope precisely. OAuth inherits whatever the signed-in user can see, which could be everything if they are an administrator. With a service principal, the scope is a Reader role assignment you make deliberately. You can choose a single subscription, several, or a whole management group.

Its activity is attributable. Reads show up in the Azure Activity Log as a distinct service principal rather than as a named employee doing hundreds of reads a day, and it’s a single identity you can review or revoke on its own.

Why choose OAuth?

The installation process. OAuth is a simple setup process. It’s a 2-3 click setup, with no other scripts or configuration. Tokens auto refresh automatically.

Token refreshes: For a service principal, you need to refresh tokens manually depending on your organization setup. Every 6, 12, or 24 months is typical unless your organization allows open-ended token expiration.