C# Access to Magento 2 SOAP API Without OAuth Token

magento2soap

I'm trying to connect a PC client application written in C# to a Magento 2 demo shop I'm hosting in a Linux VM.

I added a new integration in Magento and activated it, so I got the OAuth tokens the documentation says is required. Then I added a new service reference in Visual Studio to my Magento API with service catalogProductRepositoryV1.

I put some effort into adding the required header to the WCF communication and testet the catalogProductRepositoryV1GetList call, which returned all of my demo products alright. I then commented out the block that adds the authorization header: It still works! I even revoked all access rights for the integration in Magento – no change. I can still list all items.

How can that be? Or is authorization only required upon setting things? Or is it only required upon retrieving information that is otherwise not publicly visible?

The following code is used to demonstrate this:

using (client = new Magento.catalogProductRepositoryV1PortTypeClient())
{
    /*using (new OperationContextScope(client.InnerChannel))
    {
        MessageHeader head = MessageHeader.CreateHeader("Authorization", "", String.Format("Bearer {0}", "..."));
        OperationContext.Current.OutgoingMessageHeaders.Add(head);
    }*/

    Magento.CatalogProductRepositoryV1GetListRequest r = new Magento.CatalogProductRepositoryV1GetListRequest();
    r.searchCriteria = new Magento.FrameworkSearchCriteriaInterface();
    r.searchCriteria.pageSize = 50;

    Magento.CatalogProductRepositoryV1GetListResponse response = client.catalogProductRepositoryV1GetList(r);
}

EDIT

By browsing the REST API documentation I noticed that some GET calls on APIs for public data (such as categories, items, etc.) don't return an unauthorized error, while other calls on sensitive data like order items do also return errors for GET calls.

Maybe my suspicion is correct and data that's public anyway is not protected by authorization.

Best Answer

Yes, your suspicion is correct and data that's public anyway is not protected by authorization (for resources marked with anonymous role)