I registered my app at https://apps.dev.microsoft.com/.
1- I am trying to access calendar rest api. To perform the oauth2, i need the client secret. I can't seem to find the client secret. There is the option for password or private key but using both of those throws an error. Can you please tell me where to find the client secret?
2- There are multiple documents talking about multiple ways of registering an app. Should i register my app at https://apps.dev.microsoft.com/ which using the following end point or authorization:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
or the make an account on Azure AD and use the following end point:
https://login.microsoftonline.com/common/oauth2/authorize?
Have a look at the https://msdn.microsoft.com/office/office365/HowTo/authentication-v2-preview, especially the "Restrictions on app registrations" section.
Certain limitation are applied depending on how you register a new app.
At this time, all apps that want to integrate with the v2.0 app model must create a new app registration at apps.dev.microsoft.com. Any existing Azure AD or Microsoft Account applications will not be compatible with the v2.0 app model, nor will applications registered in any portal besides the new App Registration Portal. There is no migration path for an application from the generally available Azure AD service to the v2.0 app model.
Similarly, apps registered in the new App Registration Portal will work exclusively with the v2.0 app model. You can not use the App Registration Portal to create apps that will integrate successfully with the Azure Active Directory or Microsoft Account services."
Depending on your needs you should pick how you register your app.
You get the secret by clicking Generate Password in the Application Secrets section when you're viewing your app registration on apps.dev.microsoft.com. If you generate one and don't copy it, you can never retrieve it! If that's the case, you can remove the old secret and generate a new one. There's a walkthrough of registering and getting your secret at https://dev.outlook.com/RestGettingStarted/Tutorial/dotnet (section 3).
I recommend you use apps.dev.microsoft.com.
Related
I am trying to create an AD application using .net, I am able to create it with Microsoft.Azure.ActiveDirectory.GraphClient. But why I am supposed to create a native AD Application in the Azure portal prior to creation of AD Application in .net
My question is, will I be able to create a AD application without client Id of a native app?
In short no.
When you create application you need to require Delegate permission or Application permission. To assign the permission to user, you need to use app to act as an agent.
You could use the following code to get the ad token, you need to give the client id of the native app which you have granted delegate permission. You also could grant Application permission to a Web app/API which you use client id and client secret to acquire token.
var result = await authenticationContext.AcquireTokenAsync(graphResourceId, clientId, new UserPasswordCredential(userName, password));
BTW, Azure portal is an enterprise application.So, when we login and create Azure AD App, it also get the client id of azure portal.
You can simply publish your native .NET application using AAD Application Proxy. There are a number of samples that show how to do this. You need to publish your application through the application proxy and register it as a Native app.
This document details all of the steps for this: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-native-client-application
I am quite new to the wonderful world of Azure development. I currently work on a Xamarin.Form project with an Azure backend. After researching a lot, I found this post: https://azure.microsoft.com/en-in/resources/samples/active-directory-b2c-xamarin-native/
that explain how to do signIn in Azure from XF2.4.
But I am a little bit lost in all the portal offered by Microsoft. I create my backend on the portal.azure.com and at first I create the application in the portail.azure too. But I rapidly understand that I need to use the new apps.dev.microsoft.com to create the application. Now I am able to Singin from my XF project correctly.
My question: it is the correct way to do that? Now I try to add some Admin and "Normal user" application roles, then assigned roles to users. But the application created in the apps.dev.microsoft.com is not listed in the AzurePortal and the configuration available in apps.dev.micorosft.com is very simple.
How I can do that? Thanks
To register an app that works with the v2.0 endpoint, you must use a new app registration portal: apps.dev.microsoft.com . And refer to document :
The v2.0 endpoint does not support issuing role or group claims in ID tokens.
The workaround would be add users to different groups , use microsoft graph api in you application to get user's group membership , then model Role based access control on top of Security Groups.
In addition .If you want to use Azure AD B2C , you should register the app in b2c application blade . And refer to this thread for how to manually retrieve these claims the group claims(need register a separate application) and inject them into the token.
Is it possible to set up a single "Native app" which can be used by users on different Azure accounts/directories so they can get data from their Office 365 Sharepoint Online?
We can get this working using a "Web app" because in the Azure portal where you set this up it has the "Multi-tenanted" option which can be set to Yes - the notes for this support this:
Designates whether users in external organizations are allowed to
grant your app access to data in their organization's directory. This
control affects only the ability to grant access. It does not affect
any access that has already been granted.
And some early testing suggests this does indeed work. However this implies using an Oauth secret which must be embedded in the app and the notes here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code
State (in relation to the app secret):
....It should not be used in a native app, because client_secrets
cannot be reliably stored on devices. It is required for web apps and
web APIs, which have the ability to store the client_secret securely
on the server side.
For native apps, the docs here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview
State:
Native client registrations are multi-tenant by default. You don’t
need to take any action to make a native client application
registration multi-tenant.
Which suggests they should work in the way we desire - however when we test this with OAuth flow from an account not in the same Azure AD where the native app was setup we get the following after authenticating:
AADSTS70001: Application with identifier 'XXXXXXXXXXXXXXXXXXXXXX' was not found in the directory YYYYYYYYYYYYYYYYYYYY
So it appears this does not work. At present the only way it seems to make this work is to create a Web app and embed the client ID and secret in the native application.
Has anybody had success with multi-tenant native apps or any ideas/feedback on what I am doing wrong or could try?
UPDATE I realised there were two things wrong here:
* You can actually click on the "Manifest" button in Azure and edit the raw JSON, updating the 'availableToOtherTenants' value to make it multi-tenant.
* I didn't have the scope=user_impersonation in the OAuth flow.
Now it seems we can create a native app which users in other orgs/tenants can authenticate with.
UPDATE 2 OK so it turns out our app now works for some users but at least one is getting:
AADSTS65005: Invalid resource. The client has requested access to a resource which is not listed in the requested permissions in the client's application registration. Client app ID: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA. Resource value from request: https://XXX.YYYYYY.com. Resource app ID: ZZZZZZZZZZZ. List of valid resources from app registration: 00000002-0000-0000-c000-000000000000, 00000003-0000-0ff1-ce00-000000000000.\r\nTrace ID: KKKKKKKKKKKKKKKKK\r\nCorrelation ID: CCCCCCCCCCCCCCCCCCC
I can't see why it would work for one user but not another if both are in different tenant/Azure ADs to where the app is created.
If you were developing an native app which access the multi-tenant web API which also developed by you, you can set the add the clientId of native app to the manifest of web app's manifest with knownClientApplications property. So that when other tenant's users access the multi-tenant web API, it will also register the native app to their tenant.
Refer the code sample below which demonstrates a Windows Store application calling a multi-tenant web API that is secured using Azure AD:
active-directory-dotnet-webapi-multitenant-windows-store
I need to implement authentication for azure web api using azure active directory.
client app(which consumes webapi) may or may not be in azure. how i need to authenticate user, where i should generate token if my app is not in azure(if it is IOS app). authentication should work in all cases even if client app is in azure or not.
Please let me now the best procedure to implement authentication.
You need to define the client app in Azure AD as a native app in the case of a mobile app. Then you define the API there, and add your client permissions to access it. You can optionally customize the available permissions through the API app's manifest in Azure AD. Then when your mobile app opens, you would have to authenticate with Azure AD, and then request an access token for the API. That you can then use to authenticate requests.
I can't answer this question in too great detail because it is quite a large topic and how it is done also depends on your platform. There is a sample app that you can check which does exactly what you want. The whole list of examples for native apps can be found here.
App Service to use different authentication providers Azure Active Directory,Facebook,Google,Microsoft,Twitter.
We can set any type of Authentication/Authorization in the Azure Portal.More info about how to use authentication for API Apps in Azure App Service, please refer to document.
By default, App Service provides authentication but does not restrict authorized access to your site content and APIs. You must authorize users in your app code.
I'm creating a Node app that uses OAuth2 to login a user and use the Office365 API to send and receive email, and possibly contacts and calendar events.
I have no need for Azure Active Directory that I know of. However, I am unsure of whether or not I need to register the app with Azure for the OAuth flow.
At first I followed this tutorial, which involves registering the app in the "Application Registration Portal." The OAuth token I receive currently works with the REST API for Outlook. No Azure.
Then I saw this tutorial, which seems to suggest that any app using the Office365 APIs should register an app with Azure. I don't want to do this if I don't have to, mainly because of the cost.
It is not clear to me why I need to sign up for one or the other, and my main concern is that the first tutorial is dated to the point that my app's registration with the "Application Registration Portal" will become deprecated and I will need to switch over to registration with Azure at some point. I have seen plenty of outdated tutorials and information from MS that are not clearly marked as deprecated. Can anyone help clear this up?
Sorry for the confusion. The short answer is that both these methods are still relevant, so none of them are deprecated yet.
Firstly, you're right that you need to register your app to call the Office 365 APIs.
And, you're also right that there are currently two different places to register an app: the App Registration Portal and the Active Directory section under the Azure Management Portal.
Registering on either one of these is enough to get you to a comfortable state where you can call the Office 365 APIs.
However, the convergence of the Outlook.com stack with the Exchange stack means that you are now also able to use the Office 365 Mail, Calendar and Contacts API against consumer Outlook.com accounts in addition to Office 365 accounts. If you wish to take advantage of this, you should register your app in the Application Registration Portal and NOT the Azure Management Portal.
Another advantage of registering through the Application Registration Portal is the support of dynamic permissions scopes. You don't have to specify upfront when you register your app what permissions it requires; rather, you can request permissions at runtime using the scopes parameter.
This new v2 app model for apps registered in the Application Registration Portal is currently in preview. A reason not to register apps in the Application Registration Portal is if they will be using more than just the Mail, Calendar and Contacts APIs. e.g. if your app is also using the OneDrive for Business Files API, you wouldn't be able to request tokens using the v2 app model's endpoint. In that case, you should register your app in the Active Directory section under the Azure Management Portal.