Azure AD implementation for SPA / WebAPI application having both on the port/HostEnv.?

Question

I am trying to implement Azure AD authentication in a SPA application. I am using an OWIN Startup.cs file in the WEB API and ADAL.js file in the angularjs front end application. (as per most of the tutorials suggestion)

My application does not have WebAPI and UI hosted in different domains/port. Basically, the WebAPI is referenced in the UI application project. (So no need for enabling CORS).

Now I have registered the applications on the Azure AD separately. ie ClientApp -> Reply URL: http://localhost:90/ and WebAPI -> APPID SignOn URL: http://localhost:90/Api/V1/

I have configured the ADAL.js and also getting the login page when trying to access the application from the UI. Also, I am able to retrieve the id.token generated after logging through the URL redirection. Also have decorated the web api controllers with the [Authorize] attribute.

My main concern here is that, if I try to call the WebAPI directly using tools like postman, I am getting access denied/Unauthroized Access (401). Can someone pls explain how can I test on my local env. with this scenario?

My sample request is: http://localhost:93/Api/V1/User/Preference (GET) I am adding the token in the Authroization property of the Headers in the web api call.

Also a side note, I don't think I require OWIN/Startup.cs file for securing the WebAPI. The way I tried is that I got the token value send through the headers and got the AudienceID using JwtSecurityToken and parsing the contents of the Authroization property. Is this approach right as per security or I should stick to the OWIN implementation.

Answer 1

All of the ADAL JS tutorials have the backend API and the UX hosted on the same domain and port, with no need for CORS. See for example https://azure.microsoft.com/en-us/resources/samples/active-directory-javascript-singlepageapp-dotnet-webapi/ . Those samples demonstrate that you need only ONE Azure AD registration, as the JS layer is in effect the exact same app as the web API. We do have some samples demonstrating how to call an external API as well, and those do require CORS- but only for the extra API. The logic for calling the app backend remains the same (just one Azure AD app registration, no need for CORS).Postman doesn't offer any opportunity to pop out UX, hence one strategy you can follow is to obtain the tokens you need beforehand. The use of OWIN allows you to centralize the auth setup; if you add auth in the controller, you'll need to repeat that logic for every new controller you add. Also, maintaining the code will be harder as you might use API surface that requires code changes when you update the assemblies, while that's less likely to happen if you use the standard middleware setup