entra1-3  Exercise 1: Put the Sign-in Events in Order
=====================================================

THE ORDER (using the exercise's own numbering)
----------------------------------------------
 Order  Event  What it is                                   Step  Route
 -----  -----  -------------------------------------------  ----  ---------------------------
   1st    4    Browser is sent to /authorize with           1     Through the browser
               client_id, redirect_uri, scope, state
   2nd    6    User types password and approves MFA on a    2     Through the browser (on a
               Microsoft page                                     Microsoft page)
   3rd    2    Browser arrives at the callback with a       3     Through the browser
               code and state
   4th    1    Acme's server sends the code, client ID      4     DIRECTLY server to Entra
               and client secret to /token
   5th    5    Entra replies with access_token, id_token,   5     DIRECTLY Entra to server
               expires_in
   6th    3    Acme validates the ID token (signature,      6     Inside Acme's own system
               aud, iss, exp) and sets its session cookie

WHERE AN EXPIRED CLIENT SECRET SHOWS UP
---------------------------------------
At event 1 (4th in order). That is the first and only place in this flow where
Acme's own credential is presented to Entra. Events 4, 6 and 2 all happen
without it, so the user can get all the way through the Microsoft sign-in,
including MFA, and still fail afterwards. Entra's reply to event 1 would be an
error (invalid_client) instead of the tokens at event 5.

WHAT THE USER AND THE CLIENT WOULD SEE
--------------------------------------
Everything looked fine at the Microsoft end (they signed in) and then Acme's page
reports a failure. That mismatch is itself a clue: "I signed in successfully on
the Microsoft page, then it failed when I came back" points at the redemption
step, not at the user's account.

WHY THIS WORKS AS AN ANSWER
---------------------------
It ties each message to a step and a route, and finds the credential's single
use in the flow. Knowing that the secret is first used at step 4 explains why
users can pass the sign-in but still be refused, and why the failure is the same
for everyone at that client.