So after doing some digging, it sounds like it is sort of how I was expecting. Guest users authenticate against a external AAD instances by authenticating against their hosting AAD or MS Account instance. The hosting AAD or MS Account instance provides a guest token that is then given to the external AAD instance and is then validated and access is given based on different parts of that validation.
Here is a breakdown of ID Tokens
Some requirements for the validations (The ones I'm currently interested in):
- oid - an object id unique and cannot be changed. It can be used across multiple applications or accounts.
- sub - another unique id specific to this account. Again this id cannot be changed, however it can only be used for a singular application.
- tid - a guid specific to an AAD Tenant. This can not be changed
- preffered_username / email - both can be changed
Please correct me if I'm wrong, but these are my takeaways from this process.
- The tenant ID is also likely validate as well, and if that's differs from the original tenant ID the user was registered from then the token wouldn't be rejected.
- oid is created upon the original guest user authentication (or maybe even at the user accounts original creation?), and thus an account with the same email on another aad tenant would have a different one and again the token would be rejected.
- sub is created likely at authentication to an app, which means again the token would be rejected if the email was used on a different AAD tenant.
- Emails can change, so if my company or an external company gets a new domain those emails can changed without having to re-share those resources or creating a new guest account.