OAuth: default scopes for Microsoft instance are misleading

[Dzieni]

I was trying to fetch emails from Outlook using this guide: https://github.com/osTicket/docs/blob/master/OAuth2/Microsoft%20Authorization%20Guide.rst

The problem is that tutorial defines different scopes in Azure than the defaults specified in the instance setting, and it's not mentioned that it should be applied.

I managed to make the email working using the scopes suggested in the tutorial, so:

offline_access https://outlook.office.com/IMAP.AccessAsUser.All https://outlook.office.com/SMTP.Send

Makes sense, as to fetch & send emails osTicket uses IMAP and SMTP protocols.

Not sure where it should be fixed:

• one option is to change the default scope in the plugin,
• second option is to update the tutorial so that the scopes are properly changed when setting up a mailbox.

I'll be happy to make a PR for both, but I have to know which solution you find the best :).

[JediKev]

@Dzieni

Because we found that you need both https://outlook.office.com/IMAP.AccessAsUser.All https://outlook.office.com/SMTP.Send scopes enabled and consented in the App Registration but https://outlook.office.com/Mail.ReadWrite covers everything (IMAP/POP + SMTP). So no changes are needed at all. You can obviously change the scopes if you want as what we provide is just defaults but everything works as is.

Cheers.

[Dzieni]

@JediKev

So do I understand correctly that https://outlook.office.com/Mail.ReadWrite covers everything, but you still have to add https://outlook.office.com/IMAP.AccessAsUser.All and https://outlook.office.com/SMTP.Send in the app registration permissions?

My journey has started by looking at offline_access https://outlook.office.com/Mail.ReadWrite in the instance settings - after that I simply went to Azure and created an app that has both of those permissions covered, and IIRC* it wasn't enough. Then I found the tutorial and saw that you have to add explicit IMAP and SMTP permissions (and Mail.ReadWrite is not mentioned in the app configuration at all, despite being used in the instance settings), which made me extra confused.

*IIRC is important here as I had to fight with various little server annoyances on my way, so it could be something else that led to authentication error.

Sounds like an interesting quirk from MS. In any case, thanks for the explanation. I think we can close this issue - if somebody like me gets lost in a similar way, hopefully Google lead him to this thread :)