Why does Microsoft sign-in redirect so many times?

OAuth is part of the trip, not necessarily the whole trip. An app can send the browser to a sign-in endpoint, which may need to figure out the account and organization, check an existing session, and return an authorization result to the app. The app might then have another step to establish its own session.

Different products and organization settings can add steps, so the number of visible hops isn't a reliable measure of how complicated the OAuth flow itself is. Also, the browser address bar won't show every token exchange. Some happen outside those visible page redirects.

The useful way to answer this for a particular product is to capture the sign-in in your browser's network tools. Preserve the log across page loads, then follow the redirect responses and their destination addresses. Compare the relevant requests with Microsoft's authorization code flow documentation.

That should help distinguish the app's own redirects from the identity service's steps. Be careful sharing a capture, though. URLs, headers, and cookies can contain sensitive session or authorization data.

Organization policies can change the path too. A straightforward setup may look much simpler than one with additional security or access controls. Seeing extra hops doesn't by itself tell you whether they're required by a policy or just part of how that product handles sign-in.

There's a difference between a few redirects and getting stuck in a loop. Session cookies can be involved when sign-in breaks after a network change, but the visible redirects alone won't tell you why. Clearing the relevant cookies may get a session working again, though it also removes useful evidence for troubleshooting.

It can feel especially odd next to an app that signs in silently or only visibly redirects once. A lot depends on whether there's already a usable session and how that particular app handles authentication. Fewer visible hops don't necessarily mean fewer checks happened.