entra1-2  Exercise 2: Read a Configuration Sheet
================================================

THE FICTIONAL SHEET
-------------------
    Tenant ID .................... 11111111-1111-1111-1111-111111111111
    Application (client) ID ..... 22222222-2222-2222-2222-222222222222
    Object ID (app registration) . 33333333-3333-3333-3333-333333333333
    Object ID (enterprise app) ... 44444444-4444-4444-4444-444444444444
    Authority ................... https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111/v2.0
    Redirect URI ................ https://app.acme.example/auth/callback
    Client secret value ......... (hidden)

LABELS
------
  Tenant ID ............ the client's tenant (the organisation's Entra instance)
  Application (client) ID  the application's globally unique ID; the value your
                         system quotes when it asks Entra to sign someone in
  Object ID (app reg) .. the application object's own ID, in the home tenant
  Object ID (ent. app) . the service principal's own ID in this tenant
  Authority ............ the sign-in endpoint root for this tenant; contains the
                         tenant ID
  Redirect URI ......... the exact address in your system where Entra may send the
                         user back after sign-in
  Client secret value .. the credential your system uses to prove its identity

SAFE TO SHARE ON A TICKET?
--------------------------
  Tenant ID, client ID, object IDs, authority, redirect URI:
      These are identifiers, not secrets. They're normally fine to put on a
      ticket inside your support system, because they identify things rather
      than unlock them. They are still worth handling carefully; don't post them
      publicly.
  Client secret value:
      Never. A secret on a ticket, in chat or in an email can be used to sign in
      as the application. Record only where it is stored and when it expires. (The
      portal also shows a separate secret ID for each secret, which is not the
      value; Chapter 4 looks at how secrets are shown.)

WHY THE SAME CLIENT ID CAN APPEAR IN TWO TENANTS BUT OBJECT IDS DIFFER
----------------------------------------------------------------------
There is one application object, in the home tenant, and the client ID belongs to
the application as a whole. Where the application is used in other tenants, each
tenant gets its own service principal, which is a separate object with its own
object ID. So the client ID is the same everywhere, while the application object
ID (home tenant only) and each service principal's object ID are different.

When someone says "the ID", the safe reply is: which ID, and from which page?

WHY THIS WORKS AS AN ANSWER
---------------------------
It separates identifiers from secrets and explains the one-to-many relationship
between the application object and its service principals, which is the root of
most ID confusion.