2

We have Setup a Windows azure active Directory to protect a Web API. The Web API exposes an OData3 Endpoint, it works great. Now i am trying to connect with Excel to this odata endpoint. It does not work. I also found the answer, e.g. on this stack overflow post: WAAD Authentication with WebAPI OData service consumed by Excel PowerQuery

Basically the Problem is:

AAD doesn't support first party client (PowerQuery) to third party service (your service) authentication today. but hopefully soon enough :) Maybe just when you get the rest done :)!

Okey, I understand you need to register any client app in Azure Active Directory if you want to access a web api or web app that is protected by AAD. But what i really don't get: With any browser i can authenticate against protected resources? Why does this work, i mean i am not registering the Browsers but they are actually nothing else than a Client!? I can authenticate against my Service with any browser, but with Excel it is not working. Why? Maybe i mess up something but some Explanation would be really helpfull to solve my node :)

Thank you in advance Best Laurin

Community
  • 1
  • 1
LaurinSt
  • 952
  • 11
  • 25

1 Answers1

1

The reason is that while a native client assets an identity during the token acquisition flow, however weakly, the browser does not. The browser is just a rendering engine that makes the interaction with the user possible, but there's nothing in the protocol interactions that identifies the browser. The real client, in that case, is the server code that is being executed at every request. The general idea is that whereas an application can act in independence, even when the user is not present, that is not the case for the browser - the browser is just a tool in the hands of the user (hence the user-agent denomination) and once the user walks away, all activity ceases. Unfortunately the current limitations aren't something you can work around - in a nutshell, the Excel entry in Azure AD cannot be updated to list each and every 3rd party service as requested resources. The main workaround is to register your own client, in which case you have freedom to list any service you want, but plugging things back into existing clients is hard. Sorry! We are working on solving this issue, but I dont have a timeline to offer at this time.

vibronet
  • 7,364
  • 2
  • 19
  • 21
  • Hi vibronet. thank you very much for your appreciated reply! Okey but from a security perspective this is not really clear to me. I mean any client could emulate a browser, right? (e.g. a win forms app that opens a browser let's the user login and extracts the token, like ADAL does). So it is not safe to register a client or not. How does AAD determine if it is a registred client or a browser? Just by checking the user-agent? So why is this client registration needed, what are the considerations behind this if it is not secure in the end? Sorry i am still a mess :-) – LaurinSt Aug 31 '15 at 10:53
  • Hi vibronet :) an answer on my comment would be really great in case you find some time!! :) – LaurinSt Sep 15 '15 at 14:31
  • Browser flows give you only an idtoken for signing in the web site, that is not the token that allows you to call web API as it lacks key claims (scopes). It's not as much what you actually use in term of means (app or browser) but of what is recorded in the directory in terms of permissions (what clientid can call what) and what is required for obtaining such tokens (app credentials, user credentials..). If in the directory there is no delegation entry that says a certain client can get tokens for a certain resource, whether you use an app, a browser or fiddler won't lead to a viable token. – vibronet Sep 15 '15 at 23:55