ews-managed-api
ews-managed-api copied to clipboard
OfficeDev
EWS + OAuth2 does not work with V2 endpoint
Follow example here: https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-authenticate-an-ews-application-by-using-oauth
Login with an outlook.com account and you successfully get a token, but when you call:
var ewsClient = new ExchangeService();
ewsClient.Url = new Uri("https://outlook.office365.com/EWS/Exchange.asmx");
ewsClient.Credentials = new OAuthCredentials(authResult.AccessToken);
// Make an EWS call
var folders = ewsClient.FindFolders(WellKnownFolderName.MsgFolderRoot, new FolderView(10));
You get:
Error: System.ArgumentException: The given token is invalid.
at Microsoft.Exchange.WebServices.Data.OAuthCredentials..ctor(String token, Boolean verbatim)
at Microsoft.Exchange.WebServices.Data.OAuthCredentials..ctor(String token)
at EwsOAuth.Program.<MainAsync>d__1.MoveNext() in C:\Users\dev\source\repos\EWS\EWS\Program.cs:line 43
Any suggestions?
Reproduced by the auth library:
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/1274
To be clear, the example works with an Office365 account but not with an Outlook.com account.
We're receiving a token that is failing the regex in OAuthCredentials.cs.
Instead of a JWT token, we're getting a MSA token: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/1274#issuecomment-512195054
Even if we disable the regex, the MSA token does not seem to work with EWS - getting a 403.
I'm facing the exact same issue. /consumers/oauth2/v2.0/authorize + /consumers/oauth2/v2.0/token is giving an access_token which is giving a 403 when trying to do a SyncFolderHierarchy operation. I'm pasting the complete curl request & response here - access_token is expired
POST /ews/exchange.asmx HTTP/1.1
User-Agent: CloudMagic
Host: outlook.com
Accept: */*
Authorization: Bearer EwBQA+l3BAAUv0lYxoez7x2t6RowHa2liVeLW/wAAcemsxMONlRiFpll/Vda6qlpHHuL8YBFl8rfhmscopCVEUMXxAAwDwqJddnLe+/Ie/Syllt4jb1DMKc0Ne3nCpZz+cFVI7Gl0gqfbt+GNBdshKa7N3MKaHuIpZ43WFFMnwW3I0uctz1jE/tgwuhU7GrqHuEILIu0m9bAcfgjSt6WeeM8xGGx9VcLbzhzqfKMPy2rxn9xrULZ3OcnTObkw+uFz6ZIEmiDHqZDWi6Q8M5mwLjbP7Rpot6aBGtYo15ZTfIb6g/OHMThAvQuecLOOCmOhDZhZKLOza7R4zqTJe4UDEN8IP5+CyWbTganei1XdhRFTDW8v3XKrDhu9jkN8YUDZgAACKGjmjIrzxGxIAKROyZnwakRxIQudh2JXRwATsqEPKQjr++xvAqvDURp/+HThY5x+LdFVNmgcMJjzdHCvgEqBaoX3IExNPvTYavSX6+ANEM6IZc5T4VRabjvvZ50KUaZKU3TEFt+L0KU90es4h/7mfFjmkVaurXQ78aNcduX5D6IoVmF2tS8YHqqNodGotxuttX3Pgkvc/iBqlkRTPN31wjqW9rDClU4+lmu8pbUA8+wL58A2yK34IgFnrboSPIYDCf8aka1csVQiiSk2AtLTu2eVXBHnVihbXJwlrgFJ28zoHO1Nd68n14aGVCBnZnj05/avdthoih7hNw7sjvv1F0kRVC0kiifoOG7DvQxm/eQkfQwAwIQOxfxeH+ZCTkqTidQUnCX+KEQ788V8sJOq0YQ3F43YPCCWGurH5r7OBjS+Edye1xlt4LHpwgFBVUsuWG8A6Do+oOK7gbdYURCDdLrXu9UPcjdt0IDZX6AgnoNxKYd6NqE2kib/jxQOehLYSSVVSTyinVk32ERDQEhqbzdXbl85KI5PZh05GBGa9+mVhMtbGcpt+90vNr+76ndwJQKZUv/2cM7sFgpv5DPWppxKTzJ9NZGGxFoU0cC07PsvIolxos2UbLTY/OIrKV3KHYiuk/8RxtTN2xxWH8HT+XDYMY7pxFSiXLlb1u3u4lnuSzNrMiNVMkXtLBONUhOjfa8HSWWsiyi1AuQjGgpBzQWq+zp1Pw3fvazUAI=
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://schemas.microsoft.com/exchange/services/2006/messages/SyncFolderHierarchy"
Content-Length: 496
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"><soap:Body><m:SyncFolderHierarchy><m:FolderShape><t:BaseShape>IdOnly</t:BaseShape></m:FolderShape></m:SyncFolderHierarchy></soap:Body></soap:Envelope>
X --REQUEST ENDS---------------------------------------------------------------------- X
HTTP/1.1 403 Forbidden
Cache-Control: private
Server: Microsoft-IIS/10.0
request-id: 1d2a4d87-3d37-464a-8b36-53b76a74334d
X-CalculatedFETarget: SG2PR06CU003.internal.outlook.com
X-BackEndHttpStatus: 403
Set-Cookie: exchangecookie=53238ab47a8043de9d4fcd5f7464eabd; expires=Thu, 23-Jul-2020 09:05:47 GMT; path=/; secure; HttpOnly
X-FEProxyInfo: SG2PR06CA0094.APCPRD06.PROD.OUTLOOK.COM
X-CalculatedBETarget: SG2PR06MB3275.apcprd06.prod.outlook.com
X-BackEndHttpStatus: 403
X-RUM-Validated: 1
x-ms-appId: 0000000048297E67
X-AspNet-Version: 4.0.30319
X-BeSku: WCS5
X-DiagInfo: SG2PR06MB3275
X-BEServer: SG2PR06MB3275
X-FEServer: SG2PR06CA0094
X-Powered-By: ASP.NET
X-FEServer: BN6PR2001CA0024
Date: Tue, 23 Jul 2019 09:05:47 GMT
Content-Length: 0
I'm requesting https://outlook.office.com/EWS.AccessAsUser.All, along with email, profile, offline_access and openid scopes in case that is relevant.
I'm seeing the same behaviour on outlook.office365.com host as well. Further to that the exact same operation works fine with Office365 accounts. It also works with outlook.com accounts when replacing the bearer token auth with basic auth which makes me think that MS has completed the migration to EWS but haven't migrated the authentication servers.
@ashwinswy Yup. I got some more insight when I posted the same thing on: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/1274 but no one at MS seems to be taking ownership of this.
This issue has been brought to the attention of the PM who owns the EWS API. Thanks for your patience.
Hey guys, running into the same issue. I think it is with the offline_access scope, when I remove that everything is fine. But add it back on then it breaks. @darrelmiller
How's their progress on this issue? @darrelmiller
Removing offline_access is pain when you are relying on MSAL library... @royalgiant
Microsoft: "We're phasing out basic auth from Exchange"
Also Microsoft: "Sorry but our new lib is buggy, has no docs and overall does not work"
I also landed on this issue after migrating from the V1 to V2 OAuth endpoint in hopes of Outlook.com users working through the same flow as Office 365 users.
I tried removing the offline_access scope but still receive a 403 error when trying to make any EWS request.
Unfortunately, it does not seem to work.
I just tested trying to get around this by using the /Common/ tenant, and left out offline_access, so just Ews.AccessAsUser.All, but get this:
AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope 'Ews.AccessAsUser.All' is not configured for this tenant.
😢 Does this mean, no delegated EWS access to Outlook.com? Ouch if so.
Just remembered, for self-service, you can setup an App Password in your own Microsoft account (MSA), and then do basic auth, and that way at least lets you manage the mailbox with EWS Managed API. I knew that I got into my Outlook.com account with EWS recently, but forgot that part. I've been messing around with OAuth / EWS a lot recently, and managed to forget this.
Wish OAuth / delegated was possible though, would have been nice. MS Graph it is though, for now and the future.
Hitting the same issue as https://github.com/OfficeDev/ews-managed-api/issues/229#issuecomment-741876010.
Let me get this straight. The posted example on docs.microsoft.com doesn't work. Microsoft has known about this issue for over 2 years and still hasn't managed to fix the bug or update their docs to at least warn people about the bug. New folks (like me) are going to follow the MS docs, fail to get it to work, and eventually stumble upon this post. Microsoft, I'm embarrassed for you. It's like you don't even care anymore. Two freaking years, with no resolution. That's crazy!
Well. EWS is deprecated. No new work is going into this from Microsoft, it has been announced some time ago... The way forward is Graph (Exchange Online) or basically nothing (Exchange OnPrem)
Just in case you have not seen it: https://techcommunity.microsoft.com/t5/exchange-team-blog/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/ba-p/608055
Exchange Web Services will not receive feature updates
Starting today, Exchange Web Services (EWS) will no longer receive feature updates. While the service will continue to receive security updates and certain non-security updates, product design and features will remain unchanged. This change also applies to the EWS SDKs for Java and .NET as well. While we are no longer actively investing in it, EWS will still be available and supported for use in production environments. However, we strongly suggest migrating to Microsoft Graph to access Exchange Online data and gain access to the latest features and functionality.
The article states the requirement for a Microsoft 365 account. A lot of work was done to allow Microsoft Graph to transparently work for both M365 accounts and Microsoft Consumer Accounts. I'm presuming that work has not been done in EWS and is not likely to happen based on its current state.
What would be really useful is to know what capabilities are needed that currently not supported via Microsoft Graph. Using Microsoft Graph to access M365 services is the supported mechanism.
What would be really useful is to know what capabilities are needed that currently not supported via Microsoft Graph.
@darrelmiller What would be a proper channel to communicate this? My team is just migrating our software from some legacy protocols (EWS for Microsoft 365 accounts and IMAP, SMTP, ActiveSync for Consumer Accounts) to the MS Graph API and we have a growing list of things that are completely missing or difficult to implement.
@darrelmiller We are a Microsoft Partner that uses EWS to ingest data in Office 365 mailboxes with the EWS UploadItems functions, to preserve as much data as possible from the source systems, and to have decent performance without a lot of overhead. This is definitely totally missing from Graph currently.
@MichelZ just checking, but are you only concerned here about Microsoft personal/consumer accounts? I'm asking because Ews Managed API works great with OAuth2 for work/school accounts. It is even supported with EXO App Access policies.
Just looking at the last few comments I don't see what target mailbox type (MSA vs Organizational), but the issue was opened for Consumer mailbox scenario.
@JeremyTBradshaw We are not affected by this here, we use Work/School accounts fine with EWS. I'm mostly concerned about the deprecation, and the very recent announcement that you won't be able to register new OAuth Apps with EWS permissions starting from September 2022. We massively rely on this functionality.
@MichelZ ahh I see it now (this: https://techcommunity.microsoft.com/t5/exchange-team-blog/upcoming-api-deprecations-in-exchange-web-services-for-exchange/ba-p/2813925).
I feel your pain, but I bet they will either postpone or succeed in replacing all functionality with MS Graph equivalents.
I have forwarded this thread to the appropriate people internally. Your feedback on how important it is to make this existing functionality available in Microsoft Graph is extremely helpful for us to motivate folks to do the right thing. Keep it coming.