4

I'm trying to write a C# console app that will register an application in Azure Active Directory. It should work just as the web application project creation wizard in VS 2013 when you Change Authentication and select Organizational Accounts in Azure.

Following the fiddler trace, I can see that it authenticates the user using wsfederation and an oauth2 token and then uses the graph.windows.net graph api to configuration the AAD directoryObjects service principal and application.

I have tried to use the sample Graph API app, but it requires the app be registered first so that I have the clientId (application id) and password (key) to send in the Acquire Token request using the Windows Azure AD Authentication Library for .NET.

I've tried using a bunch of the different Azure APIs but they all have my chicken and egg problem, I want to use an unregistered client application to register an application in AAD. I need to avoid Configuring Application Authentication and Authorization for the Graph API so that the user has no manual steps.

Does anyone know how Visual Studio does it, using just the user login with browser prompt or if there is a standard application id and password that can be used to access the graph API, like there is the standard login URL, https://login.windows.net/common? Some C# samples would be greatly appreciated.

This post does the Application creation, but requires a clientId and password, which I don't think I have.

Community
  • 1
  • 1
mgrowan
  • 380
  • 4
  • 16

1 Answers1

5

You can't register a new application using the Graph API from an unregistered client. The only reason the VS2013 flow works is because VS2013 is already registered in a special way within Azure AD -- it's a first party application and has unique permissions. In my Fiddler trace, VS2013 uses a client ID of 872cd9fa-d31f-45e0-9eab-6e460a02d1f1. Technically you can use this client ID and the redirect URI of VS2013 to initiate sign-on with Azure AD. This still involves user interaction (the user has to authenticate via browser pop-up) so it doesn't meet your requirement for "no manual steps," but it's somewhat helpful for understanding the protocol flows and how registration works.

The bottom line is that if you want to call the Graph API without user interaction (client credential flow), the client needs to be registered with the proper application permissions.

Sean Osterberg
  • 844
  • 4
  • 10
  • Thanks @sean-osterberg. When I said no manual steps, I more meant having to go somewhere else to configure things before running a configuration app. Prompting the user for Credentials and required configuration Urls etc is fine. Regardless, using the VS Client ID seems to work: `_authenticationContext = new AuthenticationContext("https://login.windows.net/common"); var token = _authenticationContext.AcquireToken("https://graph.windows.net", "872cd9fa-d31f-45e0-9eab-6e460a02d1f1", new Uri("urn:ietf:wg:oauth:2.0:oob"));` Thanks! – mgrowan Apr 17 '14 at 20:44
  • Yep, that works, but it's not recommended. I'm curious as to why you want to do this. It seems like you want to bootstrap some configuration for an app that can authenticate to any tenant. If so, you really should be registering a multi-tenant app in your directory and then allow your users to consent to that application. Care to share your use case? – Sean Osterberg Apr 17 '14 at 20:56
  • We want to provide our app to be hosted by our partners and authenticated with AAD of existing Office 365 clients. When the partner wants to provision a new client we want them to be able to create a new instance and register it with the clients AAD. At the moment the client would have to, go activate their Azure Portal, go to Directory > Application > Add > Copy Key > modify web.config etc. We just want to provide them with a tool they run, answer prompts and all is configured. I did look at the multi tenant option, but I understand that only works if you have a single hosted instance? – mgrowan Apr 17 '14 at 21:39
  • 1
    I think this would be a better way than using VS' client ID: Have your partner create a single native app registration in their own directory. Do everything like you're doing now but with the new client ID instead, pointing to the common endpoint. This way you're not using a first party's client ID, which isn't recommended and may become untenable in the future. UX is slightly different, but better for the customer in my opinion -- they will be prompted with a consent dialog, showing the requested perms. This dialog shows your partner's company name. Everything else would work the same. – Sean Osterberg Apr 18 '14 at 20:13