none
Cannot authenticate OData feed using an Organizational Account RRS feed

  • Question

  • Hi all,

    I'm trying to consume a WebAPI OData (v3) web service, which required a token-based authentication using Azure Active Directory.
    PowerQuery cannot access the resource anonymously, and therefore I have to supply a different sort of credentials.
    However, if I choose "Organizational account" and attempts to "Sign it", I get the following eror: "Unable to connect. This credential type is not supported for this resource".

    Does anyone know what might be the problem?

    Thanks!


    • Edited by OB3ll Wednesday, February 4, 2015 7:14 AM Typo in title
    Wednesday, February 4, 2015 7:11 AM

Answers

  • Yes, that is true. By "Microsoft AAD tenant", I mean that it's a Microsoft service (vs a non-Microsoft customer of AAD). There's a limitation in AAD today where client applications and services are either "first party" (i.e. a Microsoft product) or "third party" (anyone else), and first party applications can only access first party services. I'm not sure why Hadeel didn't lead off with the last paragraph of her answer, but she's the OAuth person on our team and I can assure you she knows what she's talking about.
    • Marked as answer by OB3ll Sunday, February 8, 2015 9:07 AM
    Sunday, February 8, 2015 8:44 AM

All replies

  • Due in part to technical limitations in the AAD service, we can only support Microsoft AAD tenants. I'm hopeful that this will change during CY2015.
    Wednesday, February 4, 2015 2:10 PM
  • Dear Curt,

    I'm not entirely sure I understand. I am indeed an AAD tenant.

    I described my case more thoroughly here: http://stackoverflow.com/questions/28293791/waad-authentication-with-webapi-odata-service-consumed-by-excel-powerquery, and as far as I understand, it is currently impossible for PowerQuery to autneticate in front of AAD and use the token when accessing the OData feed.
    Could you confirm that this is true?

    Sunday, February 8, 2015 6:56 AM
  • Yes, that is true. By "Microsoft AAD tenant", I mean that it's a Microsoft service (vs a non-Microsoft customer of AAD). There's a limitation in AAD today where client applications and services are either "first party" (i.e. a Microsoft product) or "third party" (anyone else), and first party applications can only access first party services. I'm not sure why Hadeel didn't lead off with the last paragraph of her answer, but she's the OAuth person on our team and I can assure you she knows what she's talking about.
    • Marked as answer by OB3ll Sunday, February 8, 2015 9:07 AM
    Sunday, February 8, 2015 8:44 AM
  • Thank you both very much for your answers!

    If you could please refer me to where I could post a feedback/request to the AAD team on this issue, that will be great.

    Thanks again!

    Sunday, February 8, 2015 9:13 AM
  • Do you know if AAD now supports third party client apps?
    Tuesday, January 12, 2016 3:19 PM
  • Nope, not yet.
    Tuesday, January 12, 2016 5:39 PM
  • Does ADD now support first party client (PowerQuery) to third party service authentication?
    Saturday, July 23, 2016 4:22 PM
  • Yes. I don’t think there’s any formal documentation yet, but I can describe it.

     

    Let’s say the user’s endpoint is “https://foo.com/bar”. To access it from Power Query, they enter this URL into the “From Web” option and are then prompted for an authentication type. They pick “Organizational account” and click “Login”. At this point, we make an HTTP request to the URL that was entered, and in the header of the request we include “Authorization: Bearer”. We then expect the HTTP response to have a “WWW-Authenticate” header which contains the information we need in order to use AAD to start a login flow. That may look something like this:

     

    WWW-Authenticate: Bearer authorization_uri="https://login.windows.net/a1a2578a-8fd3-4595-bb18-7d17df8944b0/oauth2/authorize"

     

    The GUID is usually determined by your AAD instance. This cannot be done entirely via configuration, it involves writing code on the service side.

     

    As a final note, the AAD application must support the “user_impersonation” scope; this is the scope we’re hardcoded to use.

    Tuesday, November 1, 2016 3:26 PM
  • Hi Curt,

    I'm trying to do something similar, but using my own OData API protected by Bearer tokens with an OpenID Connect authorization flow.  Is this possible with Power Query?

    I've been trying to set my own OIDC authorization endpoint in the authorization_uri parameter of WWW-Authenticate, but Power Query shows the error "The token service reported by the resource is not trusted."

    If I replace my authorization_uri with something like "https://login.windows.net" it works and fires up a browser instance.

    Is there some sort of hard coded restriction happening?  And, if so, is there any workaround where I can use my own OIDC Provider with Power Query?

    Thank you!



    Thursday, December 15, 2016 9:02 PM
  • I second this question. We're trying to use OIDC authorization powered by our internal ADFS and we do face the same "The token service reported by the resource is not trusted." error.

    I would think that the "Approved ADFS Authentication Services" setting has been introduced exactly to address this issue, but there does not seem to be an obvious way to add any ADFS servers there.

    Wednesday, September 12, 2018 11:31 AM