I have long-standing problems authenticating SMTP using the V2 authorize and token endpoints and with the scopes set in Graph using the REST APIs and not MSAL. There appears from StackOverflow posts to be a widespread misunderstanding of the relationship between client scope URIs and AAD permissions URIs and so perhaps the Express team could resolve once and for all the question at the end of this post.
BACKGROUND
MSFT said that SMTP AUTH would not be included in Graph - and hence in its permissions list - but only in Office365. But it then unexpectedly appeared in Graph, and an enable/disable switch added to the tenant (accessible via Powershell) which could be overridden at user level (accessible via a pulldown in the user account). What was not widely publicised was that the default for new tenants was ‘disabled’, and this is at the protocol level so did not just affect Oauth2.
Apparently less well known was that access tokens issued for the Graph API were V1 tokens even though they were requested from a V2 endpoint (V2 endpoints can issue V1 tokens and vice versa.) because access tokens are always of the type (version) appropriate for the API so you cannot mix API types in the same client scopes list. This caused us endless head-scratching when debugging during development.
However this is not true for ID tokens which always conform to the endpoint version that issued them.
Finally, the access token scopes list must not span APIs anyway, so the client code needs to request tokens one by one. Since authorization codes cannot be reused, the common workaround appears to be to use the refresh token (acquired along with the first access token by specifying offline_access) to request a new access token for the second API, and so on.
As ledniov and others have commented, IMAP and SMTP AUTH scopes appear only to work when the scope URI in the client is either outlook.office.com or outlook.office365.com but the corresponding permissions in AD are in set in Graph and not in ‘legacy’ Exchange (the Exchange API simply does not have an SMTP.Send for example whereas Graph does). At this point my brain goes numb because scopes requested by a client (including the resource API’s URI - which for the V2 endpoints defaults to graph.microsoft.com if no URI is specified) for an access token MUST be a subset of the permissions for that API set by admin in AAD for that client or the entire granular permissions model falls apart.
@Sivaprakash_saripalli in a reply to question StackOverflow question 61597263 commented: “IMAP, SMTP scopes are targeted for Exchange resource and not Graph. Whereas User.Read, Mail.ReadWrite are meant for Graph resource”. Since many of us are confused at this apparent inconsistency, it would be appreciated if Sivaprakash or colleague could explain how if we specify an SMTP AUTH scope using https://outlook.office.com/SMTP.Send we should specify this permission to AAD when (e.g.) SMTP.Send is only selectable for Graph and not the Exchange API? Or is there a difference between a ‘scope’ URI used in the client and the corresponding permission URI specified for that API in AAD?