entra1-3  Exercise 2: Read the ID Token Payload
===============================================

THE CLAIMS
----------
  iss  .................. issuer: who created the token, and the tenant the user
                          was authenticated in (here the tenant ending ...3333)
  aud  .................. audience: the application the token was issued FOR (an
                          ID token's audience should be your application's
                          client ID)
  tid  .................. the tenant the user signed in to
  oid  .................. the user's immutable object ID (same across apps,
                          different in each tenant)
  sub  .................. the subject, immutable but different for each app
  name  ................. a display name (can change; display only)
  preferred_username .... a human-readable username (mutable; not for access
                          decisions)
  nonce  ................ echo of the value sent with the sign-in request
  exp  .................. the time on or after which the token can't be accepted

WHICH CLAIM IDENTIFIES THE USER?
--------------------------------
Use oid (or sub), together with tid to say which tenant. Do not use name,
preferred_username or email: Microsoft states they are mutable, may be reused
and must not be used to identify a user or to make authorization decisions.

WHY THE TOKEN MUST BE REJECTED (FOUR REASONS)
---------------------------------------------
 1. Wrong audience:  aud is 99999999-... but Acme's client ID is
                     22222222-... The token was issued for a different
                     application. Microsoft says to reject an ID token whose aud
                     doesn't match your application's ID.
 2. Wrong tenant:    tid and iss point at tenant 33333333-... but this sign-in
                     should be from Fabrikam's tenant 11111111-... (a token from
                     another tenant must not be trusted for Fabrikam).
 3. Expired:         exp is 08:00 UTC and the time now is 10:30 UTC.
 4. Wrong nonce:     the token carries xyz789 but your system sent n-0001, which
                     suggests a replayed or mixed-up token.

(A fifth check, not testable here, is the signature against Entra's published
keys; a real library does that first.)

HOW A SUPPORT ENGINEER USES THIS
--------------------------------
You rarely validate tokens by hand. The skill is knowing which claim answers which
question when a client says "it says wrong tenant" or "it says token not for this
application":
   aud mismatch  -> the wrong client ID in your settings, or the user went
                    through a different application.
   tid / iss     -> the wrong tenant; check the tenant card (Chapter 1).
   exp           -> expired token or a clock problem.
   nonce         -> a session or replay problem.

SECURITY NOTE
-------------
A real ID token is a credential until it expires. Do not paste one into a ticket
or an online decoder; copy only the claim names and values you need.

WHY THIS WORKS AS AN ANSWER
---------------------------
It links each rejection to a specific claim and to the expected value on your
side, and it shows that the identifier you key users on is oid/sub plus tid, not
anything a person can change.