Single sign-on across SharePoint and Entra ID
A SharePoint-hosted application made users sign in twice — once to SharePoint, then again to Entra ID for the app's own API calls. A small thing that quietly erodes trust in an internal tool, every single day.
The engagement
The second prompt came from the app acquiring its own tokens independently of the SharePoint session. The obvious fixes all reached into tenant-wide identity policy — exactly the kind of change a client's security team is right to refuse on behalf of one application.
I migrated the app to the SharePoint Framework's Entra token provider, so it acquires tokens against the existing authenticated session instead of starting its own. It was deployed through the site-collection app catalog, keeping the change scoped to where it was needed — no tenant-level policy change, no security review of the whole estate. The migration was written up as a handoff so the client's own developers could repeat the pattern.
One sign-in. The app calls its API on the user's existing identity, the second prompt is gone, and nothing about the tenant's identity posture had to change to get there.
Practice areas applied
- Security & Compliance Engineering. Bake security reviews, threat modeling, and policy-as-code into every sprint so compliance becomes automated instead of a bottleneck.