%3CLINGO-SUB%20id%3D%22lingo-sub-1353758%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1353758%22%20slang%3D%22en-US%22%3E%3CP%3EAre%20there%20any%20popular%20IMAP%20Clients%20already%20supporting%20OAUTH%20authentication%3F%20Thanks%20Christian%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1354119%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1354119%22%20slang%3D%22en-US%22%3E%3CP%3EThunderbird%2077%20supports%20IMAP%20using%20OAuth2%20on%20Office%20365.%20See%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1528136%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1528136%20%3C%2FA%3Efor%20more%20details.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1354695%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1354695%22%20slang%3D%22en-US%22%3E%3CP%3EI%E2%80%99ve%20read%20the%20linked%20documentation%20several%20times%20now%2C%20and%20as%20far%20as%20I%20can%20tell%2C%20there%E2%80%99s%20no%20way%20for%20automated%20(non-interactive)%20applications%20or%20daemons%20to%20access%20Exchange%20Online%20mailboxes%20using%20IMAP%20with%20OAuth.%20Or%20am%20I%20missing%20something%3F%20The%20issue%20is%20requesting%20tokens.%20The%20doc%20suggests%20that%20only%20two%20OAuth%20flows%20-%20Authorization%20Code%20Flow%20and%20Device%20Authorization%20Grant%20Flow%20-%20are%20supported%20by%20IMAP.%20Neither%20of%20which%20appears%20to%20be%20suitable%20for%20non-interactive%20auth.%20The%20doc%20also%20states%20that%20%E2%80%9C%3CSPAN%3EOAuth%20access%20to%20IMAP%2C%20POP%2C%20SMTP%20AUTH%20protocols%20via%20OAuth2%20client%20credentials%20grant%20flow%20is%20not%20supported%E2%80%9D%20and%20that%20is%20the%20flow%20recommended%20by%20Microsoft%20for%20server%20to%20server%20or%20non-%3C%2FSPAN%3E%3CSPAN%3Einteractive%20apps!%20The%20suggestion%20is%20to%20use%20Graph%20API%20%E2%80%9Cif%20your%20application%20needs%20persistent%20access%20to%20all%20mailboxes%20in%20an%20tenant%E2%80%9D.%20But%20we%20just%20need%20individual%20non-interactive%20applications%20to%20have%20access%20to%20specific%20mailboxes%20via%20IMAP%20using%20OAuth.%20Or%20can%20we%20use%20any%20OAuth%20flow%20via%20the%20MSAL%20client%20libraries%2C%20including%20ROPC%20or%20Windows%20Integrated%20Authentication%20that%20should%20support%20non-interactive%20auth%3F%26nbsp%3B%3C%2FSPAN%3EWe%20have%20many%20non-interactive%20apps%20that%20use%20IMAP%20to%20programmatically%20access%20EXO%20mailboxes.%20If%20not%2C%20how%20are%20these%20apps%20supposed%20to%20migrate%20to%20OAuth%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1357233%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1357233%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F272511%22%20target%3D%22_blank%22%3E%40stukey%3C%2FA%3EExactly%20my%20question%20also.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1357598%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1357598%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F324116%22%20target%3D%22_blank%22%3E%40The_Exchange_Team%3C%2FA%3E%26nbsp%3Bit%20would%20be%20great%20to%20clarify%20this%20in%20your%20blog%20post.%20We%20have%20discussions%20again%20that%20we%20can%20get%20rid%20of%20app%20registrations%20with%20this%20news.%20But%20for%20applications%20with%20non-interactive%20users%2C%20like%20deamons%20or%20reporting%20tools%2C%20it%20is%20still%20needed%20to%20go%20through%20an%20app%20registration%20with%20application%20permission%2C%20right%3F%3C%2FP%3E%3CP%3EYou%20need%20to%20create%20an%20app%20registration%20anyway%20as%20far%20as%20I%20understand.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1359171%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1359171%22%20slang%3D%22en-US%22%3E%3CP%3EI%20have%20waited%20this%20for%20some%20months.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1359490%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1359490%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F324116%22%20target%3D%22_blank%22%3E%40The_Exchange_Team%3C%2FA%3E%2C%20thank%20you%20for%20the%20update!%20I'll%20be%20using%20IMAP%20and%20SMTP%20to%20implement%20some%20functionality%20and%20this%20is%20definitely%20helpful.%3C%2FP%3E%3CP%3EI%20tried%20the%20steps%20from%20the%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fexchange%2Fclient-developer%2Flegacy-protocols%2Fhow-to-authenticate-an-imap-pop-smtp-application-by-using-oauth%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Eprovided%20instruction%3C%2FA%3E%2C%20but%20it%20didn't%20work.%20I've%20submitted%20my%20finding%20to%20the%20%3CA%20href%3D%22https%3A%2F%2Fstackoverflow.com%2Fq%2F61597263%2F1126831%22%20target%3D%22_self%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EStackOverflow%20question%3C%2FA%3E%2C%20can%20someone%20from%20your%20team%20have%20a%20look%20at%20this%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1362527%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1362527%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F272511%22%20target%3D%22_blank%22%3E%40stukey%3C%2FA%3E%26nbsp%3BE%3CSPAN%3Exactly%20my%20question%20also.%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F324116%22%20target%3D%22_blank%22%3E%40The_Exchange_Team%3C%2FA%3E%26nbsp%3B%3A%20can%20you%20clarify%20this%20for%20us%20in%20blog%20post%3F%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1373157%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1373157%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F324116%22%20target%3D%22_blank%22%3E%40The_Exchange_Team%3C%2FA%3E%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F149115%22%20target%3D%22_blank%22%3E%40Greg%20Taylor%20-%20EXCHANGE%3C%2FA%3E%26nbsp%3BPlease%20can%20you%20respond%20to%20the%20above%20questions%20from%20myself%20and%20many%20others%20regarding%20support%20for%20non-interactive%20apps%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1381176%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1381176%22%20slang%3D%22en-US%22%3E%3CP%3EThis%20feature%20announcement%20is%20for%20interactive%20applications%20to%20enable%20OAuth%20for%20IMAP%2C%20POP%2C%20SMTP.%20At%20this%20time%2C%20there%20are%20no%20plans%20to%20enable%20IMAP%2C%20POP%2C%20SMTP%20OAuth%20for%20non-interactive%20applications%20using%20client%20credentials%20flow.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1330432%22%20slang%3D%22en-US%22%3EAnnouncing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1330432%22%20slang%3D%22en-US%22%3E%3CP%3E%3CSPAN%3EEver%20since%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fexchange-team-blog%2Fimproving-security-together%2Fba-p%2F805892%22%20target%3D%22_blank%22%20rel%3D%22noopener%22%3Ewe%20announced%20our%20intention%20to%20disable%20Basic%20Authentication%20in%20Exchange%20Online%3C%2FA%3E%20we%20said%20that%20we%20would%20add%20Modern%20Auth%20(OAuth%202.0)%20support%20for%20the%20IMAP%2C%20POP%20and%20SMTP%20AUTH%20protocols.%20%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%3CSPAN%3EToday%2C%20we%E2%80%99re%20excited%20to%20announce%20the%20availability%20of%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fexchange%2Fclient-developer%2Flegacy-protocols%2Fhow-to-authenticate-an-imap-pop-smtp-application-by-using-oauth%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EOAuth%202.0%20authentication%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%3C%2FA%3E%20to%20Exchange%20Online%20mailboxes.%20This%20feature%20announcement%20is%20for%20%3CEM%3Einteractive%20applications%3C%2FEM%3E%20to%20enable%20OAuth%20for%20IMAP%20and%20SMTP.%20At%20this%20time%2C%20there%20are%20no%20plans%20to%20enable%20IMAP%20and%20SMTP%20OAuth%20for%20%3CEM%3Enon-interactive%20applications%3C%2FEM%3E%20using%20client%20credentials%20flow.%20For%20that%2C%20we%20suggest%20to%20use%20our%20Graph%20API.%20%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%3CSPAN%3EApplication%20developers%20who%20have%20built%20apps%20that%20send%2C%20read%20or%20otherwise%20process%20email%20using%20these%20protocols%20will%20be%20able%20to%20implement%20secure%2C%20modern%20authentication%20experiences%20for%20their%20users.%20This%20functionality%20is%20built%20on%20top%20of%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevelop%2Fv2-overview%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EMicrosoft%20Identity%20platform%20(v2.0)%3C%2FA%3E%20and%20supports%20access%20to%20email%20of%20Microsoft%20365%20(formerly%20Office%20365)%20users.%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%3CSPAN%3EDetailed%20step-by-step%20instructions%20for%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fexchange%2Fclient-developer%2Flegacy-protocols%2Fhow-to-authenticate-an-imap-pop-smtp-application-by-using-oauth%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Eauthenticating%20to%20IMAP%20and%20SMTP%20AUTH%20protocols%20using%20OAuth%3C%2FA%3E%20are%20now%20available%20for%20you%20to%20get%20started.%3C%2FSPAN%3E%3C%2FP%3E%0A%3CH3%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%20id%3D%22toc-hId-1143426548%22%3E%3CSPAN%3EWhat%E2%80%99s%20supported%3F%20%3C%2FSPAN%3E%3C%2FH3%3E%0A%3CP%3E%3CSPAN%3EWith%20this%20release%2C%20apps%20can%20use%20one%20of%20the%20following%20OAuth%20flows%20to%20authorize%20and%20get%20access%20tokens%20%3CU%3Eon%20behalf%20of%20a%20user%3C%2FU%3E.%20%3C%2FSPAN%3E%3C%2FP%3E%0A%3COL%3E%0A%3CLI%3E%3CSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevelop%2Fv2-oauth2-auth-code-flow%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EOAuth2%20authorization%20code%20flow%3C%2FA%3E%3C%2FSPAN%3E%3C%2FLI%3E%0A%3CLI%3E%3CSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevelop%2Fv2-oauth2-device-code%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EOAuth2%20Device%20authorization%20grant%20flow%3C%2FA%3E%3C%2FSPAN%3E%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3CP%3E%3CSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevelop%2Fv2-oauth2-client-creds-grant-flow%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EOAuth2%20client%20credentials%20grant%20flow%3C%2FA%3E%20that%20enables%20access%20without%20a%20user%20account%20is%20%3CU%3Enot%20supported%3C%2FU%3E.%20If%20your%20application%20needs%20persistent%20access%20to%20all%20mailboxes%20in%20a%20Microsoft%20365%20organization%2C%20we%20recommend%20that%20you%20use%20the%20Microsoft%20Graph%20API%E2%80%99s%20which%20allow%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fgraph%2Fauth-v2-service%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Eaccess%20without%20a%20user%3C%2FA%3E%20in%20addition%20to%20access%20on%20behalf%20of%20a%20user%2C%20enable%20granular%20permissions%20and%20let%20administrators%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fgraph%2Fauth-limit-mailbox-access%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Escope%20such%20access%20to%20a%20specific%20set%20of%20mailboxes%3C%2FA%3E.%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%3CSPAN%3EFollow%20these%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fexchange%2Fclient-developer%2Flegacy-protocols%2Fhow-to-authenticate-an-imap-pop-smtp-application-by-using-oauth%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Edetailed%20step-by-step%20instructions%3C%2FA%3E%20to%26nbsp%3Bimplement%26nbsp%3BOAuth%202.0%26nbsp%3Bauthentication%26nbsp%3Bif%20your%20in-house%20application%20needs%26nbsp%3Bto%20access%26nbsp%3BIMAP%20and%20SMTP%20AUTH%26nbsp%3Bprotocols%20in%20Exchange%20Online%2C%20or%20work%20with%20your%20vendor%20to%20update%20any%20apps%20or%20clients%20that%20you%20use%20that%20could%20be%20impacted.%20%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%3CSPAN%3ENote%3A%20We%20are%20in%20the%20process%20of%20rolling%20out%20OAuth%26nbsp%3B%3C%2FSPAN%3E%3CSPAN%20data-contrast%3D%22auto%22%3E2.0%26nbsp%3B%3C%2FSPAN%3E%3CSPAN%20data-contrast%3D%22auto%22%3Esupport%20for%20POP%20protocol%20and%20will%20update%20this%20blog%20once%20the%26nbsp%3B%3C%2FSPAN%3E%3CSPAN%20data-contrast%3D%22auto%22%3Erollout%20is%20complete%3C%2FSPAN%3E%3CSPAN%20data-contrast%3D%22auto%22%3E.%3C%2FSPAN%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CFONT%20color%3D%22%23FF6600%22%3E%3CSPAN%3EThe%20Exchange%20Team%3C%2FSPAN%3E%3C%2FFONT%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1330432%22%20slang%3D%22en-US%22%3E%3CP%3E%3CSPAN%3EEver%20since%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fexchange-team-blog%2Fimproving-security-together%2Fba-p%2F805892%22%20target%3D%22_blank%22%3Ewe%20announced%20our%20intention%20to%20disable%20Basic%20Authentication%20in%20Exchange%20Online%3C%2FA%3E%20we%20said%20that%20we%20would%20add%20Modern%20Auth%20(OAuth%202.0)%20support%20for%20the%20IMAP%2C%20POP%20and%20SMTP%20protocols.%20%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%3CSPAN%3EToday%2C%20we%E2%80%99re%20excited%20to%20announce%20the%20availability%20of%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Fjasonjoh%2Foffice-developer-exchange-docs%2Fblob%2Flegacy-protocol-oauth%2Fdocs%2Flegacy-protocols%2Fhow-to-authenticate-an-imap-pop-smtp-application-by-using-oauth.md%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%20target%3D%22_blank%22%3EOAuth%202.0%20authentication%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%3C%2FA%3E%20to%20Exchange%20Online%20mailboxes.%20%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1330432%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3Eall%20posts%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EAnnouncements%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3Edocumentation%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EExchange%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EExchange%20Online%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1407171%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1407171%22%20slang%3D%22en-US%22%3E%3CP%3EI'm%20afraid%20of%20how%20many%20multi-function%20copiers%20and%20legacy%20applications%20this%20is%20going%20to%20take%20down.%20A%20very%20real%20and%20major%20concern%20once%20OAuth%202%20is%20the%20only%20way%20to%20send%20email%20through%20the%20Exchange%20Online%20SMTP%20servers!%26nbsp%3B%3CIMG%20class%3D%22lia-deferred-image%20lia-image-emoji%22%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Fhtml%2Fimages%2Femoticons%2Fsad_40x40_1.gif%22%20alt%3D%22%3Asad%3A%22%20title%3D%22%3Asad%3A%22%20%2F%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1407183%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1407183%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F1484%22%20target%3D%22_blank%22%3E%40Jared%20Pickerell%3C%2FA%3E%26nbsp%3B-%20we%20haven't%20said%20when%20SMTP%20AUTH%20will%20require%20OAuth.%20It's%20going%20to%20take%20much%20longer%2C%20we%20know%20that.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1415310%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1415310%22%20slang%3D%22en-US%22%3E%3CP%3EWhen%20will%20Outlook.com%20support%20this%20for%20Imap%20and%20Pop%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1415378%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1415378%22%20slang%3D%22en-US%22%3E%3CP%3ETo%20be%20more%20precise%2C%20when%20will%20the%20consumer%20version%20of%20Outlook.com%20support%20modern%20auth%2Foauth2%20for%20syncing%200365%20accounts%20to%20personal%20accounts%20via%20the%20sync%20accounts%20option%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1418165%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1418165%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F149115%22%20target%3D%22_blank%22%3E%40Greg%20Taylor%20-%20EXCHANGE%3C%2FA%3E%2C%26nbsp%3BI%20didn't%20read%20closely%20enough%20so%20appreciate%20you%20clearing%20that%20up%20for%20me!%20A%20big%20sigh%20of%20relief!%20Thanks!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1426282%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1426282%22%20slang%3D%22en-US%22%3E%3CP%3E%3CSPAN%3EWith%20this%20(April%2030th%20%E2%80%9920)%20release%20of%20OAuth2%20support%20for%20IMAP%20and%20SMTP%2C%20Sivaprakash-MSFT%20commented%20on%20Stackoverflow%3A%20%E2%80%9CIMAP%2C%20SMTP%20scopes%20are%20targeted%20for%20Exchange%20resource%20and%20not%20Graph%E2%80%9D%20and%20%E2%80%9C...%20we%20will%20only%20allow%20Exchange%20resource%20URLs%20to%20work%20and%20don%E2%80%99t%20have%20plans%20to%20enable%20Graph%20resource%20URLs%E2%80%9D.%20But%20under%20AAD%20API%20permissions%2C%20SMTP.Send%20only%20appears%20as%20selectable%20when%20the%20Microsoft%20Graph%20API%20is%20selected.%20If%20I%20select%20the%20Exchange%20API%20(under%20Supported%20legacy%20APIs%20or%20via%20Enterprise%20apps)%2C%20there%20is%20no%20selectable%20SMTP.Send%20or%20%3C%2FSPAN%3EIMAP.AccessAsUser.All%3CSPAN%3E.%20So%20if%20my%20app%20uses%20a%20scope%20of%20outlook.office365.com%2FSMTP.Send%2C%20or%20outlook.com%2FSMTP.Send%20there%20isn't%20a%20matching%20permission%20in%20AD%20except%20under%20graph.microsoft.com%2F%20(apparently%20the%20wrong%20API%E2%80%A6).%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EI%20gather%20from%20Stackoverflow%20posts%20that%20there%20is%20confusion%20over%3A%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E-%20the%20URL%20prefix%20(e.g.%20%3CA%20href%3D%22https%3A%2F%2Foutlook.office.com%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Foutlook.office.com%2F%3C%2FA%3E)%20of%20a%20requested%20scope%20such%20as%20%3CA%20href%3D%22https%3A%2F%2Foutlook.office.com%2FSMTP.Send%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Foutlook.office.com%2FSMTP.Send%3C%2FA%3E%20%3C%2FSPAN%3E%3CSPAN%3Eas%20specified%20in%20an%20app%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E-%20the%20API%20selected%20in%20AAD%20to%20allow%20that%20scope%20(e.g.%20Microsoft%20Graph%20or%20Exchange)%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EPerhaps%20someone%20in%20the%20Exchange%20Team%20could%20clarify.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3ETnx%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1431894%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1431894%22%20slang%3D%22en-US%22%3E%3CP%3EIs%20it%20possible%20to%20achieve%20this%20through%20Powershell%3F%20Currently%20most%20of%20the%20internal%20automations%20use%20powershell%20and%20it%20was%20simple%20to%20send%20email%20reports%20using%20Powershell.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1434518%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1434518%22%20slang%3D%22en-US%22%3E%3CP%3EI%20guess%20the%20issue%20is%20one%20of%20delegation%3A%20how%20the%20resource%20owner%20can%20delegate%20permission%20to%20access%20his%2Fher%20resource%20to%20others%20(e.g.%20a%20website).%20It%20goes%20to%20the%20heart%20of%20MSFT's%20(and%20Google's)%20wish%20to%20manage%20delegated%20authentication%20and%20authorisation%20properly.%3C%2FP%3E%3CP%3EThe%20mechanics%20of%20sending%20are%2C%20as%20you%2C%20say%2C%20realisable%20using%20Powershell%2C%20but%20the%20authentication%20of%20Powershell%20jobs%20by%20creation%20of%20a%20service%20principal%20is%20not%26nbsp%3B%20dissimilar%20from%20OAUTH2's%20resource%20owner.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOr%20perhaps%20I%20misunderstand%20your%20comment.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1447788%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1447788%22%20slang%3D%22en-US%22%3E%3CP%3EMSAL%20libraries%20have%20been%20announced%20for%3A%3C%2FP%3E%3CP%3E-%20.NET%20(unsurprisingly)%3C%2FP%3E%3CP%3E-%20JavaScript%20and%20TypeScript%20superset%20framworks%3C%2FP%3E%3CP%3E-%20Android%3C%2FP%3E%3CP%3E-%20iOS%20and%20MacOS%3C%2FP%3E%3CP%3E-%20Java%20(for%20Windows%2C%20macOS%20and%20Linux)%3C%2FP%3E%3CP%3E-%20Python%20(Windows%2C%20macOS%2C%20and%20Linux)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBut%20lack%20of%20PHP%20support%20for%20SMTP%20AUTH%20with%20Oauth2%20will%20have%20a%20devastating%20impact%20on%20the%20zillions%20of%20backend%20apps%20that%20currently%20use%20Basic%20Authentication.%3C%2FP%3E%3CP%3EAs%20an%20example%2C%20the%20hugely%20popular%20PHPMailer%20used%2C%20I%20guess%2C%20on%20every%20Linux%20%2F%20Apache%20server%20in%20the%20universe%20supports%20Oauth2%20for%20access%20to%20Gmail%2C%20Yahoo%20and%20the%20older%20MSFT%20consumer%20mail%20platforms%20and%20(with%20some%20difficulty)%20for%20the%20Azure%20AD%20for%20developers%20(v1.0)%20endpoint%20but%20not%20for%20the%20MSFT%20identity%20platform%20(v2.0)%20endpoint%3A%20when%20pointed%20at%20V2.0%20in%20order%20to%20use%20SMTP%20AUTH%20for%20outbound%20access%20to%20O365%20Exchange%20Online%2C%20it%20will%20fail%2C%20even%20with%20the%20obvious%20changes%20to%20%E2%80%98authorise%E2%80%99%20and%20%E2%80%98token%E2%80%99%20endpoint%20URLs%20and%20to%20scopes%20(aka%20permissions).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnd%20SMTP%20AUTH%20support%20has%20only%20and%20understandably%20been%20announced%20for%20the%20V2.0%20endpoint%20so%20there%20is%20no%20way%20to%20regress%20via%20V1.0%2C%20even%20as%20a%20stopgap.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EDeprecating%20Basic%20Authentication%20is%20a%20sensible%20move%2C%20but%20Oauth2%20is%20FAR%20more%20complex%20to%20work%20with%2C%20and%20since%20MSFT%20wants%20everyone%20to%20be%20on%20O365%20(and%20why%20not%3F)%2C%20MSAL%20support%20for%20PHP%20would%20be%20appreciated.%20All%20the%20backend%20PHP%20apps%20that%20need%20to%20use%20Oauth2%20to%20access%20O365%20services%20will%20need%20rework%2C%20and%20it%20seems%20sensible%20integrate%20MSAL%20instead%20of%20direct%20calls%20to%20the%20V2.0%20endpoint.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1470535%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1470535%22%20slang%3D%22en-US%22%3E%3CP%3EIs%20the%20Oauth2%20Resource%20Owner%20Password%20Grant%20flow%20supported%20for%20SMTP%2FIMAP%3F%20I%20can't%20seem%20to%20find%20any%20information%20about%20this.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1470654%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1470654%22%20slang%3D%22en-US%22%3E%3CP%3EMy%20construing%26nbsp%3Bof%20MSFT%E2%80%99s%20announcement%20is%20that%20Resource%20Owner%20Password%20Credentials%20Grant%20(per%20RFC6749%20section-4.3)%20was%20not%20supported%20since%20they%20stated%20specifically%20that%20the%20more%20secure%20Client%20Credentials%20Grant%20(per%20RFC6749%20section-4.4)%20was%20not%20supported.%26nbsp%3B%3C%2FP%3E%3CP%3ERFC6749%20section-4.3%20reads%20as%20if%20the%20authentication%20stage%20is%20essentially%20Basic%20Authentication%20%E2%80%93%20something%20MSFT%20wants%20to%20eradicate.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPerhaps%20MSFT%20team%20will%20comment%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1470742%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1470742%22%20slang%3D%22en-US%22%3E%3CP%3EMeanwhile%2C%20I%20have%20done%20some%20testing%20(send%20an%20email%20with%20SMTP%20using%20an%20access%20token%20received%20with%20ROPC%20as%20described%20here%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevelop%2Fv2-oauth-ropc%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevelop%2Fv2-oauth-ropc%3C%2FA%3E).%20The%20implementation%20seems%20to%20work%20for%20now.%3C%2FP%3E%3CP%3EThe%20flow%20does%20seem%20to%20use%20some%20form%20of%20Basic%20Authentication%20to%20fetch%20the%20access%20token%2C%20but%20the%20SMTP%20protocol%20is%20done%20with%20Oauth2.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIs%20it%20expected%20that%20this%20approach%20will%20also%20be%20made%20unusable%20once%20Basic%20Authentication%20for%20SMTP%2C%20IMAP%2C%20etc.%20is%20disabled%3F%3C%2FP%3E%3CP%3EIt%20would%20be%20very%20useful%20for%20me%20if%20this%20solution%20would%20still%20be%20supported.%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F324116%22%20target%3D%22_blank%22%3E%40The_Exchange_Team%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1470783%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1470783%22%20slang%3D%22en-US%22%3E%3CP%3EIndeed%20-%20that%20was%20my%20take%20also.%20Since%20the%20authentication%20stage%20is%20really%20grafted%20in%20the%20front%20of%20Oauth2's%20authorisation%20process%2C%20I%20was%20assuming%20that%20any%20Basic%20Authentication%20currently%20supported%20would%20eventually%20be%20removed.%3C%2FP%3E%3CP%3EBut%20this%20is%20not%20my%20area%20and%20I%20suspect%20you%20know%20much%20more%20about%20it%20than%20I%20do!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1495824%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1495824%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F149115%22%20target%3D%22_blank%22%3E%40Greg%20Taylor%20-%20EXCHANGE%3C%2FA%3E%26nbsp%3BCan%20you%20confirm%20if%20IMAP%2FSMTP%20via%20OAuth%20will%20be%20allowed%20without%20disabling%20Security%20Defaults%20as%20described%20in%20this%20post%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Ffundamentals%2Fconcept-fundamentals-security-defaults%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Ffundamentals%2Fconcept-fundamentals-security-defaults.%3C%2FA%3E%26nbsp%3BI%20want%20to%20confirm%20a%20fresh%20O365%20user%2Forganization%20won't%20have%20to%20do%20anything%20special%20with%20their%20O365%2FAzure%20AD%20configuration%20to%20allow%20an%20OAuth%20IMAP%20connection.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%2C%3C%2FP%3E%3CP%3E-Joe%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1496973%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1496973%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F700919%22%20target%3D%22_blank%22%3E%40tDimache%3C%2FA%3E%26nbsp%3B-%26nbsp%3BROPC%20will%20work.%20But%2C%20it%E2%80%99s%20not%20recommended%20and%20should%20only%20be%20used%20for%20apps%20that%20have%20a%20high%20trust%20relationship%20with%20the%20user.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F594690%22%20target%3D%22_blank%22%3E%40jkemp1011005%3C%2FA%3E%26nbsp%3B-%20will%20double%20check%20but%20I%20believe%20IMAP%2FPOP%20will%20just%20work%20with%20OAuth%20by%20default%20for%20new%20orgs.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1497086%22%20slang%3D%22en-US%22%3ERe%3A%20Announcing%20OAuth%202.0%20support%20for%20IMAP%20and%20SMTP%20AUTH%20protocols%20in%20Exchange%20Online%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1497086%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F149115%22%20target%3D%22_blank%22%3E%40Greg%20Taylor%20-%20EXCHANGE%3C%2FA%3E%26nbsp%3BGiven%20the%20zillions%20of%20server-based%20Contact%20forms%20extant%2C%26nbsp%3B%20many%20of%20which%20will%20simply%20use%20MSFT%20services%20to%20mail%20the%20form%20onwards%20to%20the%20website%20host%2C%20it%20will%20be%20intriguing%20to%20know%20to%20what%20grant%20type%20they%26nbsp%3B%20will%20be%20converted.%20The%20sensitive%20bits%20-%20e.g.%20MSFT%20365%20credentials%20of%20the%20resource%20owner%20-%26nbsp%3B%20are%20hidden%20behind%20PHP%20or%20similar%20and%20the%20user%20of%20the%20form%20does%20not%20present%20any%20credentials%20of%20their%20own.%20This%20all%20sounds%20like%20ROPC%20...%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E

Ever since we announced our intention to disable Basic Authentication in Exchange Online we said that we would add Modern Auth (OAuth 2.0) support for the IMAP, POP and SMTP AUTH protocols.

Today, we’re excited to announce the availability of OAuth 2.0 authentication for IMAP and SMTP AUTH protocols to Exchange Online mailboxes. This feature announcement is for interactive applications to enable OAuth for IMAP and SMTP. At this time, there are no plans to enable IMAP and SMTP OAuth for non-interactive applications using client credentials flow. For that, we suggest to use our Graph API.

Application developers who have built apps that send, read or otherwise process email using these protocols will be able to implement secure, modern authentication experiences for their users. This functionality is built on top of Microsoft Identity platform (v2.0) and supports access to email of Microsoft 365 (formerly Office 365) users.

Detailed step-by-step instructions for authenticating to IMAP and SMTP AUTH protocols using OAuth are now available for you to get started.

What’s supported?

With this release, apps can use one of the following OAuth flows to authorize and get access tokens on behalf of a user.

  1. OAuth2 authorization code flow
  2. OAuth2 Device authorization grant flow

OAuth2 client credentials grant flow that enables access without a user account is not supported. If your application needs persistent access to all mailboxes in a Microsoft 365 organization, we recommend that you use the Microsoft Graph API’s which allow access without a user in addition to access on behalf of a user, enable granular permissions and let administrators scope such access to a specific set of mailboxes.

Follow these detailed step-by-step instructions to implement OAuth 2.0 authentication if your in-house application needs to access IMAP and SMTP AUTH protocols in Exchange Online, or work with your vendor to update any apps or clients that you use that could be impacted.

Note: We are in the process of rolling out OAuth 2.0 support for POP protocol and will update this blog once the rollout is complete. 

 

The Exchange Team

28 Comments
Established Member

Are there any popular IMAP Clients already supporting OAUTH authentication? Thanks Christian

Occasional Visitor

Thunderbird 77 supports IMAP using OAuth2 on Office 365. See https://bugzilla.mozilla.org/show_bug.cgi?id=1528136 for more details.

Regular Visitor

I’ve read the linked documentation several times now, and as far as I can tell, there’s no way for automated (non-interactive) applications or daemons to access Exchange Online mailboxes using IMAP with OAuth. Or am I missing something? The issue is requesting tokens. The doc suggests that only two OAuth flows - Authorization Code Flow and Device Authorization Grant Flow - are supported by IMAP. Neither of which appears to be suitable for non-interactive auth. The doc also states that “OAuth access to IMAP, POP, SMTP AUTH protocols via OAuth2 client credentials grant flow is not supported” and that is the flow recommended by Microsoft for server to server or non-interactive apps! The suggestion is to use Graph API “if your application needs persistent access to all mailboxes in an tenant”. But we just need individual non-interactive applications to have access to specific mailboxes via IMAP using OAuth. Or can we use any OAuth flow via the MSAL client libraries, including ROPC or Windows Integrated Authentication that should support non-interactive auth? We have many non-interactive apps that use IMAP to programmatically access EXO mailboxes. If not, how are these apps supposed to migrate to OAuth?

Occasional Visitor

@stukeyExactly my question also. 

Senior Member

@The_Exchange_Team it would be great to clarify this in your blog post. We have discussions again that we can get rid of app registrations with this news. But for applications with non-interactive users, like deamons or reporting tools, it is still needed to go through an app registration with application permission, right?

You need to create an app registration anyway as far as I understand.

Occasional Visitor

I have waited this for some months.

New Contributor

@The_Exchange_Team, thank you for the update! I'll be using IMAP and SMTP to implement some functionality and this is definitely helpful.

I tried the steps from the provided instruction, but it didn't work. I've submitted my finding to the StackOverflow question, can someone from your team have a look at this?

Occasional Visitor

@stukey Exactly my question also. 

@The_Exchange_Team : can you clarify this for us in blog post?

Regular Visitor

@The_Exchange_Team @Greg Taylor - EXCHANGE Please can you respond to the above questions from myself and many others regarding support for non-interactive apps?

This feature announcement is for interactive applications to enable OAuth for IMAP, POP, SMTP. At this time, there are no plans to enable IMAP, POP, SMTP OAuth for non-interactive applications using client credentials flow.

Occasional Contributor

I'm afraid of how many multi-function copiers and legacy applications this is going to take down. A very real and major concern once OAuth 2 is the only way to send email through the Exchange Online SMTP servers! :sad:

@Jared Pickerell - we haven't said when SMTP AUTH will require OAuth. It's going to take much longer, we know that. 

Occasional Visitor

When will Outlook.com support this for Imap and Pop?

Occasional Visitor

To be more precise, when will the consumer version of Outlook.com support modern auth/oauth2 for syncing 0365 accounts to personal accounts via the sync accounts option?

Occasional Contributor

@Greg Taylor - EXCHANGE, I didn't read closely enough so appreciate you clearing that up for me! A big sigh of relief! Thanks!

Senior Member

With this (April 30th ’20) release of OAuth2 support for IMAP and SMTP, Sivaprakash-MSFT commented on Stackoverflow: “IMAP, SMTP scopes are targeted for Exchange resource and not Graph” and “... we will only allow Exchange resource URLs to work and don’t have plans to enable Graph resource URLs”. But under AAD API permissions, SMTP.Send only appears as selectable when the Microsoft Graph API is selected. If I select the Exchange API (under Supported legacy APIs or via Enterprise apps), there is no selectable SMTP.Send or IMAP.AccessAsUser.All. So if my app uses a scope of outlook.office365.com/SMTP.Send, or outlook.com/SMTP.Send there isn't a matching permission in AD except under graph.microsoft.com/ (apparently the wrong API…).

 

I gather from Stackoverflow posts that there is confusion over:

- the URL prefix (e.g. https://outlook.office.com/) of a requested scope such as https://outlook.office.com/SMTP.Send as specified in an app

- the API selected in AAD to allow that scope (e.g. Microsoft Graph or Exchange)

 

Perhaps someone in the Exchange Team could clarify.

Tnx

Senior Member

Is it possible to achieve this through Powershell? Currently most of the internal automations use powershell and it was simple to send email reports using Powershell.

Senior Member

I guess the issue is one of delegation: how the resource owner can delegate permission to access his/her resource to others (e.g. a website). It goes to the heart of MSFT's (and Google's) wish to manage delegated authentication and authorisation properly.

The mechanics of sending are, as you, say, realisable using Powershell, but the authentication of Powershell jobs by creation of a service principal is not  dissimilar from OAUTH2's resource owner.

 

Or perhaps I misunderstand your comment.

 

Senior Member

MSAL libraries have been announced for:

- .NET (unsurprisingly)

- JavaScript and TypeScript superset framworks

- Android

- iOS and MacOS

- Java (for Windows, macOS and Linux)

- Python (Windows, macOS, and Linux)

 

But lack of PHP support for SMTP AUTH with Oauth2 will have a devastating impact on the zillions of backend apps that currently use Basic Authentication.

As an example, the hugely popular PHPMailer used, I guess, on every Linux / Apache server in the universe supports Oauth2 for access to Gmail, Yahoo and the older MSFT consumer mail platforms and (with some difficulty) for the Azure AD for developers (v1.0) endpoint but not for the MSFT identity platform (v2.0) endpoint: when pointed at V2.0 in order to use SMTP AUTH for outbound access to O365 Exchange Online, it will fail, even with the obvious changes to ‘authorise’ and ‘token’ endpoint URLs and to scopes (aka permissions).

 

And SMTP AUTH support has only and understandably been announced for the V2.0 endpoint so there is no way to regress via V1.0, even as a stopgap.

 

Deprecating Basic Authentication is a sensible move, but Oauth2 is FAR more complex to work with, and since MSFT wants everyone to be on O365 (and why not?), MSAL support for PHP would be appreciated. All the backend PHP apps that need to use Oauth2 to access O365 services will need rework, and it seems sensible integrate MSAL instead of direct calls to the V2.0 endpoint.

Frequent Visitor

Is the Oauth2 Resource Owner Password Grant flow supported for SMTP/IMAP? I can't seem to find any information about this.

Senior Member

My construing of MSFT’s announcement is that Resource Owner Password Credentials Grant (per RFC6749 section-4.3) was not supported since they stated specifically that the more secure Client Credentials Grant (per RFC6749 section-4.4) was not supported. 

RFC6749 section-4.3 reads as if the authentication stage is essentially Basic Authentication – something MSFT wants to eradicate.

 

Perhaps MSFT team will comment

Frequent Visitor

Meanwhile, I have done some testing (send an email with SMTP using an access token received with ROPC as described here https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc). The implementation seems to work for now.

The flow does seem to use some form of Basic Authentication to fetch the access token, but the SMTP protocol is done with Oauth2.

 

Is it expected that this approach will also be made unusable once Basic Authentication for SMTP, IMAP, etc. is disabled?

It would be very useful for me if this solution would still be supported.

@The_Exchange_Team 

Senior Member

Indeed - that was my take also. Since the authentication stage is really grafted in the front of Oauth2's authorisation process, I was assuming that any Basic Authentication currently supported would eventually be removed.

But this is not my area and I suspect you know much more about it than I do!

Senior Member

@Greg Taylor - EXCHANGE Can you confirm if IMAP/SMTP via OAuth will be allowed without disabling Security Defaults as described in this post https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-d... I want to confirm a fresh O365 user/organization won't have to do anything special with their O365/Azure AD configuration to allow an OAuth IMAP connection.

 

Thanks,

-Joe

@tDimache - ROPC will work. But, it’s not recommended and should only be used for apps that have a high trust relationship with the user.

 

 @jkemp1011005 - will double check but I believe IMAP/POP will just work with OAuth by default for new orgs.  

Senior Member

@Greg Taylor - EXCHANGE Given the zillions of server-based Contact forms extant,  many of which will simply use MSFT services to mail the form onwards to the website host, it will be intriguing to know to what grant type they  will be converted. The sensitive bits - e.g. MSFT 365 credentials of the resource owner -  are hidden behind PHP or similar and the user of the form does not present any credentials of their own. This all sounds like ROPC ... 

Occasional Visitor

 

@Greg Taylor - EXCHANGE 

@jkemp1011005 

 

Our implementation experience is that with older Exchange accounts the OAuth SMTP authentication works, but with newer accounts it does not, due to an SMTP security flag that is now default to on vs before it was off. 

 

https://answers.microsoft.com/en-us/msoffice/forum/all/office-365-smtp-authentication-failing-even-w...

 

This is a big friction point and blocker for our application. Essentially, customers use OAuth to grant SMTP and IMAP for our application with admin consent (when applicable) and we still can't auth with SMTP. This means we are still forced to have them perform basic auth. 

 

Can you all please prioritize this, we have thousands of Office 365 customers wanting this ability, especially so, given the deadlines on deprecating basic auth (which is understandable). 

 

There will be huge amounts of friction and support if we have to guide customers and their IT staff through obscure settings in the admin ... for which we couldn't even find ... and if we have to explain powershell to our end user customers ... this isn't going to happen. We can't be expected to take on that support. If OAuth SMTP scope grant is given and there is admin consent (when applicable) ... we should be able to authenticate as a delegated app.

New Contributor

@The_Exchange_Team Thanks a lot for the blog. I'm using JavaMail to connect with IMAP and SMTP to implement some functionality. 

I tried the steps from the provided instruction and add properties mentioned in JavaMail Article  I always get Authenticate Failed. Saw some post to add scope https://outlook.office365.com/IMAP.AccessAsUser.All but they are no longer available with indeed made me to add scope https://graph.microsoft.com/IMAP.AccessAsUser.All , but it didn't help always ended up with Authenticate Failed issue. I've submitted my finding to the StackOverFlow question

can someone from your team have a look at this?

 

Thanks,

Vinayak