As per below link of Microsoft, all the legacy protocol using applications need to be have modern authentication.
https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online#exchange-web-services-ews
Our application is a console application(Exchange Web Services (EWS)) that runs through a task schedular every 10 minutes.
It basically processes the emails using Aspose Email dll(version 22.8)
So what exactly we need to do from scratch to move it to modern authentication so that it work the same way after microsoft removes basic authentication on these protocols post October 1 2022.
Decided whether your going to use Delegate or Application permissions, eg how does you app run at the moment if it use EWS Impersonation then the Client Credentials Flow is the most appropriate to use
Read https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-authenticate-an-ews-application-by-using-oauth and create an Application registration and consent to it that contains either Delegate or Application Permission. If you using the Client Credential flow use a Certificate for Auth
Apose has it own support for oAuth Authentication see https://docs.aspose.com/email/net/access-mail-services-using-oauth/ (IMO there examples aren't great what i would suggest you do is use MSAL https://github.com/AzureAD/microsoft-authentication-library-for-dotnet for the Authentication and implement that in https://reference.aspose.com/email/net/aspose.email.clients/itokenprovider/ that should give you a more robust and reliable authentication process.)
I'm using EWS in a Windows Service to access different users calenders. Since office 365 basic authentication is deprecated I need to add support for OAuth. I followed the steps in this link Authenticate an EWS application by using OAuth and it works fine. However, my application is used by many customers and what I don't understand is what my customers are supposed to do. Do they also have to add my application in their 365 account? I was under the impression that a customer could find my app in a global directory or something, but I can't find any information about it.
I'm using the Gmail API in a .Net project using the client_secret.json file.
Is that totally free, or is there any cost we need to pay for using Gmail API?
Also how long is the client_secret.json valid? Is there any expiry of the file?
The Gmail API, like Gmail itself, is (currently) a free service from Google.
(Note that Google does offer additional features for various apps, and charges for those features. See "Gsuite": https://gsuite.google.com/pricing.html?tab_activeEl=tabset-companies)
There are quota (usage) limits on the API.
For client-secrets.json (credentials used for server-to-server authentication), there is no expiration. Of course, a given client secret will stop working if you revoke it (delete it) through the Google developer console.
There is no billing marked for the Gmail API however there are usage limits: https://developers.google.com/gmail/api/v1/reference/quota
The previous answers date back to 2018. Since then Google has updated its policies. Gmail API can be used freely for development purposes, but they charge a hefty one-time fee for production. For more info refer to this blog:
I'm using the new unified Outlook Rest API and it works great for Office 365 accounts but Outlook.com accounts often throw MailboxNotEnabledForRESTAPI exception. I understand there is transition going on now that will move all existing accounts to the new API. Is there an example on how to implement a backwards compatible call to the older LiveId/Windows Live SDK? The application registration portal has a check box under advanced called "Live SDK Support". What does this mean and how do I write fall back logic when a user uses my service and they have not been transitioned? Any help would be appreciated as we are trying to ship this service in the next day or so.
I writing a WCF service that is hosted in Azure as a (PaaS). The service in turn needs to talk to Sharepoint 2013 Online/Office 365.
I was looking at using the Sharepoint Client object model to talk to it, but keep getting the following error: "The remote server returned an error: (403) Forbidden"
When we login to access the SharePoint instance through a browser it usually takes you to https://login.microsoftonline.com/login.srf so you can log in using a Live Id. The problem is we are using a federated account and not a Live Id, and therefore get redirect again to a adfs site to login .
I've looked at a code sample at http://www.wictorwilen.se/Post/How-to-do-active-authentication-to-Office-365-and-SharePoint-Online.aspx that is using claims based authentication, but this always fails with an "Authentication Failed" message when trying to retrieve Saml Token.
If I understand this correctly. One way of doing this is to get the Saml Token, pass this to SPO, which will in turn return two cookies which I need to include in the requests made with the Client object model. Problem is I'm not finding any proper examples on how to authenticate using the Federated account in C#.
Can anyone point me in the right direction, as to how I might proceed authorizing my WCF service to talk to SharePoint.
Sorry if this is in the wrong forum. I'm not exactly sure whether this is an Azure issue or just SharePoint as I'm pretty new to both technologies.
Try the following blog article. The ability to access the Office 365 API was just announced last month and the ability to call this from your web service is pretty new. This article is a good tutorial on the subject.
Hi just in case that we registered as an Office365 reseller a few days ago i had to learn one painfull lession: The auth. token you get from sharepoint is only valid for 2 hours! Maybe that will change in Sharepoint 15 who knows...
I thought this could be an valuable hint because there is no known workaround...
Have you tried taking Wictor's sample code and just replacing the login.srf URL with your ADFS login endpoint?
Keep fiddler open as you try this out, and inspect the requests/responses each time, you will probably see more detail as to why things aren't working within the response body that C# hides away in its object model.
Check out this blog post too, on how to get the auth token from ADFS using anything where you can create a SOAP envelope:
http://leandrob.com/2012/02/request-a-token-from-adfs-using-ws-trust-from-ios-objective-c-iphone-ipad-android-java-node-js-or-any-platform-or-language/
I know this is an old post, but using SharePoint Online through an App without using an App Principal may be a violation of your license agreement. You should be using true OAuth and the TokenHelper class that is part of the SDK to use the app model properly.
Use an Office 365 SharePoint site to create an environment where you can use ACS to establish trust between a provider-hosted app and an on-premises SharePoint 2013 farm, just as you would if you were developing apps for an Office 365 SharePoint site.
You can visit the following link for further understanding:
http://msdn.microsoft.com/en-us/library/office/dn155905(v=office.15).aspx
I was getting a 403 while trying to do similar with the SharePoint object model. All I had to do to rectify it was include the user agent.
Answer here Using WebRequest to obtain cookies to automatically log into Sharepoint Online, getting variour errors
Hope it's of some help.