entra1-3  Exercise 3: Six Errors, Six Steps
===========================================

Descriptions of the error values are from Microsoft's documentation for the token
endpoint. The interpretation columns are the course's guidance and the cause still
needs to be confirmed in the logs (Chapter 7).

1. invalid_client  ("client credentials")
   Step:       4, redeeming the code (the credential check).
   Who acts:   Whoever holds the credential: the client's administrator if the
               registration is in their tenant (Chapter 2, arrangements B and C),
               or your team if it is in yours (arrangement A). Microsoft's own
               remedy: the Application Administrator updates the credentials.
               Both ends must then agree (Chapter 8).
   Record:     Trace ID, correlation ID, timestamp, the AADSTS number, tenant ID,
               client ID, and when the secret or certificate was created or
               last changed, if known.

2. invalid_grant  ("authorization code ... expired")
   Step:       4. The code was late, reused, or the PKCE verifier didn't match.
   Who acts:   Usually nobody; the user starts the sign-in again. If it keeps
               happening, your team checks for delays, retries or duplicate
               requests.
   Record:     The IDs and timestamp, and how long the sign-in took.

3. unauthorized_client  ("application not found in the directory")
   Step:       1 or 4: Entra can't find or won't accept this application in this
               tenant.
   Who acts:   The client's administrator checks that the enterprise application
               exists in their tenant (it may have been deleted or never
               consented), plus your team confirms the client ID and tenant ID in
               your settings.
   Record:     Client ID and tenant ID being used, and the IDs and timestamp.

4. invalid_scope  ("the provided value for 'scope' is not valid")
   Step:       1 or 4: the permissions or resource requested are invalid.
   Who acts:   Your team, since it is your request or configuration (a changed
               scope, a typo, a resource that isn't configured).
   Record:     The exact scope string, the IDs and the timestamp.

5. consent_required  ("requires consent")
   Step:       4 (or 1): the app is asking for something nobody has consented to.
   Who acts:   The client's administrator, who can grant admin consent, or the
               user if the permission allows user consent (Chapter 6).
   Record:     Which permissions are requested, and whether anything changed
               recently.

6. interaction_required  ("additional authentication required")
   Step:       2: a policy now needs more from the user (for example MFA), which
               a silent request can't do.
   Who acts:   Your system should retry with a normal interactive sign-in; if a
               policy is blocking it, the client's administrator reviews it
               (Chapter 6).
   Record:     The IDs and timestamp, and whether the user was asked to sign in
               interactively.

WHAT YOU RECORD EVERY TIME
--------------------------
The error value, the full description (including the AADSTS number), the trace ID,
the correlation ID, the timestamp, the tenant ID and the client ID. The two IDs are
what let the client's administrator find the same event in the sign-in logs.

WHY THIS WORKS AS AN ANSWER
---------------------------
It turns each error value into a step and an owner, and insists on capturing the
same identifying details every time, so that no case needs a second round of
"can you send the full message?".