Sign up for Office 365
Learn more about Office 365
In my previous Post , I reviewed how to authenticate to the Graph API using OAuth 2.0 Client credentials, where your application supplied a Client ID (Application ID) and a Secret (Application password).
So where does you get a Client ID and Secret for your application? That is the purpose of this post: the simple answer is that you would do this through the Azure Management Portal, where you register an application, which will generate a Client ID and Password, and also also configure the permissions for your app. Here are the steps to configure an application, using the Azure Management Portal:
After you have your Azure AD tenant and Azure Subscription, you can use the Windows Azure Management portal to try all the features in Azure, including hosting your application that accesses the Graph API. For now, let's focus on getting an application created in your Azure AD tenant – from the Azure Management Portal, the link to manage the tenant can be found near the bottom of the left hand side, and it titled “Active Directory”. Select this option to access your company – you will see four tabs to manage your organization including Users, Applications, Domains and Directory Integration – select Applications.
1. From the Applications Tab, select “+Add” from the bottom, and begin the App wizard, which starts the process to register a new application. Select an application Name and permission configuration, we recommend the 2nd option “Single Sign-on, Read Directory Data” to start with – you can update this later if your application requires Write permissions. Notice the Single Sign On (SSO) is offered standalone, and as part of Directory Read, and Directory Read+Write options – you may not choose to implement SSO this in your solution, but the configuration is automatically included in your Directory access. If you’re interest in Single Sign On in your application, our first walk through shows the setup and configuration of this in a sample application, and then adds Directory access – walkthrough of building single sign on, and directory access applications http://msdn.microsoft.com/en-us/library/windowsazure/dn151121.aspx
2. The next part of App registration requests the input of an App URL and App URI . The App URL is the URL where users can sign in and use your app – during the early evaluation and prototyping phase, you can set this to be http://localhost – for example, if you try building our sample application on your local machine, you can set this to http://localhost for the demo application. Note, as part of this App registration, the App wizard copies your App URL to the App Reply URL property – later you can view and change this value to be something different than the App URL. The App Reply URL is the physical address for your app where Windows Azure AD will send a token with the single sign-on response.
3. The App URI used as a unique logical identifier for your app. The logical identifier does not need to resolve to any internet address – it is simply a unique identifier. Similar to the App URL, you can set this to be http://localhost for evaluation and prototyping. If you incorporate single sign-on with your application, then the App URI it is presented by your app when sending a single sign-on request to Windows Azure AD. Windows Azure AD will then use this identifier to uniquely identify your app and send the sign-on response (a SAML token) back to your configured Reply URL.
All of the above steps, are to help you get “jump started” by getting an application ID and Secret and configuring permissions for your applications. After you’ve completed the App Wizard, you’ll be taken back to the Application page, where you should see your application listed. Currently there’s not a way to delete an application from this Portal, but we’re working on addressing that. Click on the application that you just created, you should three main sections: “Enable single sign-on with Windows Azure AD”, “Enable your app to read and write directory data”, and “Enable your app for external users”. Select the 2nd option “Enable your app to read and write directory data”, you will then see the CLIENT ID value – this is your App ID – now all you need is a Secret – in the CREATE A KEY section, click on “Configure key”, this will take a section for generating keys for you application. Select either a 1 or 2 year key, then select SAVE from the bottom – after a successful save, a key value will be generated and displayed. This is Client Secret or password – you should now save this key value to somewhere safe, since you will not be able to see this value ever again after you navigate away or logoff from the Azure Portal. Also note, that you can generate more than one key per Client ID - in fact, that is the recommended way to "roll keys" since you'll need to update keys before their expiry date.
You now have a Client ID and Secret, also known as App ID and App Password – this is all that is required to get a valid OAuth token for authenticating to the Graph API for your company, and you can start playing with accessing directory data. You have also registered the permission for your application to access the Graph API, which could have been one of the three options: no access (single sign-on only), Read or Read+Write. If you want to know more details of what happened under the covers, which includes creating an Application object and service principal under the tenant, then review our detailed information on MSDN http://msdn.microsoft.com/en-us/library/windowsazure/dn132633#BKMK_AppObject
At this point you can make develop a great single tenant application, that includes both single sign-on and Graph API access capabilities. But what happens if you want to create a Multi-tenant application and offer it to other customers hosted in Azure AD? Very easy – all the work you did for creating access to you single tenant app, can now be extended to make your application available to customers of Azure Active Directory (think about the millions of tenants who are already in Azure AD, who are potential users of your application). The great news is that you can take what you’ve done to configure a single-tenant app, with the single tenant app, and extend it to make it a multi-tenant application. Specifically, under the App configuration, there’s a switch “EXTERNAL ACCESS” that can be configured for ON, which then allows Azure AD customers to grant your application permission to call their directory. By default the configuration is OFF, indicating that your app is a single tenant application only. To transition to a multi-tenant app, there are a few configuration changes required: besides adding a logo for your application, there are two important requirements for the App URI and App Reply URL:
The App URI must be include of one your organization’s verified domains (use of the initial *.onmicrosoft.com is permitted since this is one of your verified domains), and the App Reply URL must use SSL (must use an https:// based address).
As mentioned before, more details of this application registration process, along with how a multi-tenant application is configured by customers who consent and grant access to their directory to you application is available here http://msdn.microsoft.com/en-us/library/windowsazure/dn132633#BKMK_AppObject
If you’re building a multi-tenant application, in my next post, I’ll show how you redirect your potential customers to the “grant consent page”, and what the reply looks like (sent to your registered App Replay URL) depending if the customer accepted or declined the consent. If you don’t want to wait for my next post, and want to see this now, then see the documentation located at http://msdn.microsoft.com/en-us/library/windowsazure/dn151122.aspx
So I tried following the instructions on (msdn.microsoft.com/.../hh974481.aspx) to setup a service principal so that I could run the graph api explorer. I can do this and I actually get a token back for sample apps, but whenever I try to call the graph API and even from the explorer. I get a "Authorization_RequestDenied" error with the message "The specified credentials do not have sufficient privileges to make this request." Is this because I don't have a WAAD account? Only a Office365 account?
241 Microsoft Team blogs searched, 72 blogs have new articles. 313 new articles found searching from
Really there is no help for this? Is an Azure account required to use the GraphAPI?
We have same questions as above, we are getting "bad request" when we are trying to use graph apis with office365. We followed the directions in msdn.microsoft.com/.../hh974466.aspx without success. Documentaion is not clear whether a "azure subscription" is required to use graph api's with office365 tenant. Can you please clarify the exact requirements? We already done every thing that you have suggested in above comment like creating ServicePrincipal and adding role to ServicePrincipal. But Still while trying to connect to Azure AD with the details after getting creation of the ServicePrincipal, it is throwing exception "400 Bad Request" Is it compulsory to have Azure Management Portal access to create ServicePrincipal to access Azure management portal it requires Azure subscription. Please help!
By using Powershell cmdlets for Office 365, I created the ServicePrincipal to register client application to get the access of Graph API, But when I am creating ServicePrincipal, its Application Type is Native Client by default that not allowing to connect my Web Client application. Is there any way to create ServicePrincipal with Application Type Web Client? Please guide me?