Signing in with Microsoft

How delegated OAuth sign-in for ADO Pilot will work once it ships in a future release.

Last updated

In a future release, you will be able to connect ADO Pilot to your Azure DevOps organization by clicking Sign in with Microsoft instead of pasting a PAT. The connection will be brokered by Entra ID's standard OAuth consent screen and renewed automatically — no token to copy, no rotation reminders.

How it will work

The planned flow is:

  1. On the Connect to Azure DevOps wizard step, click Sign in with Microsoft.
  2. Approve ADO Pilot's permission request on the Microsoft consent screen.
  3. ADO Pilot stores the resulting refresh token and uses it to call Azure DevOps on your behalf.
  4. ADO Pilot transparently refreshes the access token in the background — you do not have to rotate anything every 90 days.

The connection is bound to the Microsoft account that consents. As with PAT, if that user leaves your organization or has their access revoked, ADO Pilot will stop working until someone else reconnects.

Prerequisites

  • A Microsoft work or school account with access to the Azure DevOps organization you want reviewed.
  • Your Entra ID tenant must allow third-party application consent (or have an admin who can grant it on your behalf).
  • The signing user must have permission to read code, post pull request comments, and manage service hooks in the target organization. These map to the same scopes a PAT would request — see Required PAT scopes.

When sign-in is blocked

The most common reason a Microsoft sign-in fails is your tenant's Conditional Access policy. Your Entra ID admin can:

  • Allow ADO Pilot as a trusted application for your tenant, or
  • Pre-consent to ADO Pilot on behalf of all users so the consent screen is skipped.

If neither of those is possible, fall back to PAT — see Creating a Personal Access Token. The PAT path does not depend on tenant-wide consent because it uses a credential the user mints directly inside Azure DevOps.

Other failure modes you may see in v2+:

  • Multi-factor prompts loop or fail. Usually a tenant policy that forces MFA on third-party apps. Your admin can scope the policy to exclude ADO Pilot, or you can use PAT.
  • AADSTS65001 — The user or administrator has not consented. You declined consent or your tenant requires admin consent. Either re-run the flow and approve, or ask your admin to grant tenant-wide consent.
  • Sign-in works, then breaks days later. The user's refresh token was revoked (password reset, account disabled, admin policy change). Reconnect from the Integration settings page.

Today's path

In v1, every customer connects with a PAT. The wizard does not yet show a Sign in with Microsoft button. When delegated OAuth ships, you will be able to switch from the Integration settings page without losing review history, repository configuration, or your plan and billing.

For now, follow Creating a Personal Access Token.