The typical suggested approach when creating a client/server application (Typically for SPA apps) in Azure is to create one AAD application for the service (API) and another AAD application for the client application (E.g. Angular Spa). While I understand the mindset behind this, are there any implications creating one AAD application for both and share the same configurations values (ClientId...) between both applications? This simplifies the implementation, especially when there is only one type of client app (E.g. Web) that consumes the API tier.
I think you might want to take a look at the documentation as it might explain what the app registrations are meant for : https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-overview
This specific tutorial goes over the SPA Scenario : https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-spa-overview
The purpose behind creating an AAD App Registration for the Server is so that the client is able to request an access token for a the web API resource. For example, if you're trying to access the Microsoft Graph API, you would request xyz permissions to make a call to the Microsoft Graph's xyz API.
And the V2 Overview and the SPA Scenario Overview both go over this very thoroughly.
Note that you are not creating an AAD App Registration for your client, your creating one for your server and custom web API resource. So you would have a client requesting an access token with the server's information to get access to the web api.
In addition to that, you'll want to be clear on which endpoint you're using. This goes into that a bit further as well : How do I check to see if my AzureAD version is V1 or V2?
And here are some reasons why one would want to use the v2 endpoint : https://learn.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison
Related
Users in Azure Active Directory Azure
App Services for WebSite and Services
I am creating a Web Site that a Manager would authenticate with using an Azure Active Directory account. That website would offer up sales data on the staff they manage.
The service that returns the sales data for staff member A will be being called on behalf of the manager.
My question is what is the correct way to flow the "identity" of the logged in manager through the calls to the various services.
Do I simply protect the services with a System Level authentication at the level of the website and pass the manager's user identifier as a parameter in the request?
OR
Do I try and flow the oauth identity onward to the services so that they are called in the security context of the manager? If using this approach how would I do that?
In my opinion, if the your business doesn't have a high security requirement, the first option is great. But if you want higher security, you can use second option.
For second option, you need to register an application in your azure ad for your app service. Follow steps on this page. And register another application in AD to represent client app by following these steps. Then go to your client app and grant permissions to allow the client-app to call the backend-app. After that, the manager need to get access token before request the api in your app server to return sales data.
This Azure sample shows exactly what we want to acheive with an ASpNet Core Web Site calling own AspNet Core Service secured with our Active Directooy organisation
I am having some issues getting it to work but this sampple is what I was hoping for from asking this qeuestion. FWIW here is the seperate question covering the specific issue I am having implementing the sample, Why Http 401 when calling AspNet Core API secured with AAD. Our WebApp, Web API and AD Org
I want to develop a SaaS application on Azure and deploy to the Azure marketplace. This app will be able to obtain information about the user's network. (for instance VNET information). Ideally I would like to have a single-page application that would authenticate with the user who subscribed to the app, and then make calls on a backend API tier, which would make calls to Azure management API endpoints.
The Azure docs layout a number of scenarios of how apps could interface with AD. how-to guides
I believe what im trying to do most closely matches the "Build a web app that calls web APIs" flow, which is an example of OBO. My question is, is that really describing what im doing? Is "calls web APIs" really an example of invoking APIs on the microsoft azure platform?
So my understanding is that I would develop my own API app, that would accept requests from my client browser code, which would contain an oauth token, and then the API layer would derive another token to pass onto the Azure API layer?
Im trying to keep the architecture as simple as possible, but im afraid I may be misinterpreting the Azure docs.
OBO (On-Behalf-Of) allows you to exchange an access token that your API received for an access token to another API.
The important bit is that the access token must have been acquired in the context of the user and must contain user information.
The new access token will then also contain this user's info.
So it allows your back-end API to call Azure Management APIs on behalf of the current user.
This means your API can't do anything the current user can't do.
It is limited to the user's own access rights.
The other option for authentication is to use client credentials authentication,
where your back-end API uses only a client id + certificate/secret to authenticate.
In this case the token will not contain user information.
To enable this approach, the target organization's users would have to assign RBAC access rights to your app's service principal, so it can act by itself.
You could also build a flow in your app where you setup these RBAC accesses on behalf of the current user.
Personally, I would prefer to use delegated access (OBO) whenever possible, as it will block the user from doing things they cannot do.
Though on the other hand, service principal-based access allows the organization to control your app's access better.
I'm new to the Microsoft Graph API and Azure. I'd like to seek advises to which Microsoft Graph API version I should go with and whether I should be using the "Web API on-behalf-of flow" for my scenario.
I'm building a web services which can store access tokens of multiple Office 365 users from different organisations. This web services can then create web hooks via the Microsoft Graph API to get notifications about calendar appointment changes in these users' accounts, in order to sync these changes to the corresponding appointments stored on our own server.
So it's a mass Office 365 calendar syncing web service in a nut shell.
I have gone through a lot of their GitHub sample projects and managed to create web hooks with the v1 graph subscription API and was able to interact with the calendar of my dev account, all in a sample APS.NET MVC project.
But I'm very confused about the following parts:
Because this web service does not directly provide a UI, so the login UI would be presented by a separate desktop (WPF) client, and I believe when this is done on the client side, I can forward the authenticated access token to my web service to create the web hooks? This sounds like the "Web API on-behalf-of flow" scenario Microsoft described here: https://learn.microsoft.com/en-au/azure/active-directory/develop/active-directory-v2-limitations.
Because this web service needs to create web hooks to multiple Office 365 accounts from different organisations. I'm not sure if this counts as the a multi-tenant scenario. If this is the case, it looks like I can only use the v1 API because the v2 API only allows the web service to receive tokens from an application that has the same application ID (also described in the page linked above).
Microsoft Graph and Azure AD developers could you please shed some light on this part for me? Microsoft isn't doing the best job when it comes to documenting these parts.
Because this web service does not directly provide a UI, so the login UI would be presented by a separate desktop (WPF) client, and I believe when this is done on the client side, I can forward the authenticated access token to my web service to create the web hooks? This sounds like the "Web API on-behalf-of flow" scenario Microsoft described here: https://learn.microsoft.com/en-au/azure/active-directory/develop/active-directory-v2-limitations.
Yes, the scenario is on-behalf-of flow and this flow is not supported for the v2.0 endpoint at present.
Because this web service needs to create web hooks to multiple Office 365 accounts from different organisations. I'm not sure if this counts as the a multi-tenant scenario. If this is the case, it looks like I can only use the v1 API because the v2 API only allows the web service to receive tokens from an application that has the same application ID (also described in the page linked above).
You can only use Azure AD V1 endpoint, because the V2.0 endpoint doesn't support on-behalf-of flow. And here are some steps for using V1 endpoint for your reference:
register 2 apps, one for the WPF(native app) and one for your web service(web app)
enable the multi-tenant for the app for web service
grant the relative Microsoft Graph permission to the web app
set the knownClientApplications for the web app using the clientId of the native app
grant the relative Microsoft Graph permission and web app to the native app
After that, when the users login-in in WPF first time in different tenant, the users can conesent the two apps at same time. And then the service principals of two apps will be register to users' tenant. After that the web service can use the on-behalf-of flow to get the access_token for Microsoft Graph based on the token from native app.
More detail about multi-tenant developing, please refer below:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
And the code sample below also be helpful:
Calling a downstream web API from a web API using Azure AD
Scenario: I already have a registered multi-tenant web application that is compatible with Azure SSO. I'm now in the process of developing an iOS application that will support SSO authentication for the app as well.
Based on the example provided in https://azure.microsoft.com/en-us/resources/samples/active-directory-ios/ I created a Native application for the iOS app with delegated permissions from my WebApp (ref: https://stackoverflow.com/a/29810124).
This works for any user that exists within the AAD that the app was created. However, as soon as I want to SSO from a different domain that has previously authorized the WebApp I get an error:
Application with identifier 'CLIENT_ID_HERE' not found in directory DOMAIN_HERE.onmicrosoft.com
This implies that the native application is not multi-tenant? This seems a bit bizarre considering it should be possible for users outside of the domain to SSO to an application.
Right now, for my browser based SPA I'm simply able to manually call the common Azure login page to consent and get an authorization code for a user. I then send this code to a backend (the WebApp) that performs the OAuth handshake and gets a valid token. This does not require a client_secret from the application because the SPA isn't actually performing token retrieval.
So when I attempted to use the WebApp's client_id instead (similar to what https://stackoverflow.com/a/27033816 is suggesting) I was met with an error with the Azure AD iOS SDK requiring that I provided a client secret as well. It seems that the SDK is abstracting a fair amount of this and grabbing a token for you rather than performing a step when I can simply get an authorization code and send it to my WebApp.
TLDR: My requirements are very similar to the ones outlined in multiple-tenant, multiple-platform, multiple-services single sign-on using Azure Active directory where I have multiple clients (browser, iOS, Android) that all need to be able to use Azure SSO. I'm assuming the mobile apps should be able to use my existing WebApp to authenticate the users.
The question posed in the answer of the previous SO post somewhat explains my issue:
How can my mobile app access my multi-tenant web api on behalf of the user?
References
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-authentication-scenarios#native-application-to-web-api
https://github.com/Azure-Samples/active-directory-dotnet-webapi-multitenant-windows-store
At present the native app which register on the Azure portal doesn't support multi-tenant. You may consider using the V2.0 endpoint which also support the Microsoft accounts.
TLDR: My requirements are very similar to the ones outlined in multiple-tenant, multiple-platform, multiple-services single sign-on using Azure Active directory where I have multiple clients (browser, iOS, Android) that all need to be able to use Azure SSO. I'm assuming the mobile apps should be able to use my existing WebApp to authenticate the users.
Did you mean that have different font-end and the Multi-Tenant Web Application is the back-end? In this scenario, there is no need to register another native client application on the portal, you can refer here about add authentication for the iOS app.
So the majority of Microsoft's tutorials use their AAD SDK to generate OAuth access tokens whereas I needed to simply get an authorization_code to send up to a backend that's registered as an existing multi-tenant web application so it could properly generate a token using its own client_id.
This was done using the correct redirect_uri in the AD OAuth code documentation:
For native & mobile apps, you should use the default value of urn:ietf:wg:oauth:2.0:oob
Note that sending up urn:ietf:wg:oauth:2.0:oob will actually result in a schema error for the multi-tenant OAuth login page (https://login.windows.net/common/oauth2/authorize) so you must use https://login.microsoftonline.com/common/oauth2/nativeclient instead.
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.