Hi @ktvtrifork,

Thank you for the questions. Can you please clarify your scenario for us? Are you trying to validate the token issuer?

Also, there are some changes coming to this token API. If you can wait a few days, we'll have a formal blog post detailing everything. That should answer all your questions and more.

Let me assign this issue to @besiler to follow up.

Hi @AlexJerabek,

Thanks for the quick reply :)

What we are trying to achieve is actually to validate that a given user comes from a known domain. With the twist that it should work for older outlook desktop clients as well as OnPrem (hybrid) and O365. which means that the only token we can get is the Exchange identity token, as that is supported all around and way back. Since the Exchange identity token does not include the users email in the claims, we would have to rely on something else. This is where (if stable) the last part (following the @ ) of the iss/appcontextsender is in question. If that is stable and follows the observed convention (to either be a TennentId or a domain name), then that would indeed be a valid way to validate whenever a given user belongs to a given domain.

I willl look forward to this new blog post, where will it be posted exactly? :)

Hi @ktvtrifork,

Thank you for the additional information. I'll have @besiler follow up.

The blog will be on the M365 Developer Bloghttps://devblogs.microsoft.com/microsoft365dev/), but I'll be sure to link to it from this issue.

Hi @ktvtrifork,

Here is the blog explaining the current state and future of Exchange tokens: https://devblogs.microsoft.com/microsoft365dev/new-nested-app-authentication-for-office-add-ins-legacy-exchange-tokens-off-by-default-in-october-2024/

Given that we are moving to Nested App Auth, I'd advise reworking your authentication logic to no longer use EWS tokens. @besiler and I are happy to answer further questions on this matter on that we've publicly announced NAA.

Hi @AlexJerabek
Thanks a lot :)
Interesting, so if I'm getting this right, OnPrem stays the "same", but for office 365 NAA would be the solution, correct?

Which means that to support both OnPrem and office 365, we would need to implement both solutions. (NAA & Exchange identity tokens)

Which brings up the previous questions about the format of the Exchange identity token:

1. is appctxsender composed of a "unique identifier"@domain ?
2. is the "unique identifier" unique per exchange server or per domain?

Hi @ktvtrifork,

Sorry for the delayed response in tracking down the answers to your questions. First, yes, your summary of the NAA update is accurate - On Prem stays the same.

is appctxsender composed of a "unique identifier"@Domain ?

Generally speaking, "Appctxsender" denotes what app created the "appctx". For the Exchange Identity Token this should be always "ExchangeAppID@Tenant", meaning Exchange itself created it in a particular deployment.

is the "unique identifier" unique per exchange server or per domain?

The unique identifier is a GUID, so you should be able to rely on it being unique. I will continue to try and verify this internally.