1

I have configured the Azure AD Authentication for my asp.net core project using the services of "Microsoft.AspNetCore.Authentication.*" packages. The project is expected to be deployed to Azure App Service as a Web App.

While I enabled Azure AD authentication, I also see there is an option to enable the same at the Web App level through Application Settings on Azure Portal.

enter image description here

I have question around which option is recommended. I do see when I don't leverage Azure AD authentication configured via nuGet packages, I don't have OpenId connect service plugged into the StartUp.cs file. And I think these services are pivotal in populating the authentication properties like User.Identity.Name. On the other hand with just portal enabled authentication, I don't see this information populated. So, I presume if I want to do further work with logged in user's identity, like leveraging current claims information for authorization, I won't be able to achieve that with portal only authentication.

Nitin Rastogi
  • 1,446
  • 16
  • 30
  • I believe "portal only" is OAuth. OAuth would be handled like a third-party login provider, so you'd need an an actual user object in your application to associate that login with. The user information in OAuth comes via claims. You'd essentially use the user claims to create/find the appropriate user object, and then sign that user in, just as you would with Twitter, Facebook, etc. – Chris Pratt Aug 04 '17 at 17:00
  • Thanks Chris! Sounds like I should still be able to create a User object based on the claims received. I did check the response through fiddler in both cases and could see same result set. This suggests the framework services I added via the nuGet packages is simplifying that task for me and is taking care of generating the user object. And if I want to do the same with portal enabled authentication, I will have to set up the necessary objects. – Nitin Rastogi Aug 04 '17 at 17:05
  • I haven't worked with Azure AD, but based on what I know about OpenID, the difference is that the user object is entirely external with OpenID. It's similar in functionality to SSO, where the website simply trust the data from the authenticating source. OAuth is a different beast. It's more of an authentication factor. – Chris Pratt Aug 04 '17 at 17:10
  • 1
    In simpler terms. With OpenID, the "user" exists and is managed with the provider. With OAuth, the "user" exists and is managed by the application. – Chris Pratt Aug 04 '17 at 17:12
  • @ChrisPratt OpenId Connect is built ontop of the OAuth2.0 protocol. Both protocols the identity is owned by the identity provider. In OAuth2.0, the Identity provider is granting access (through an access token) to a resource; however, OpenId Connect is about the identity provider authenticating the user and providing some basic info to the app about who the user is (through an ID Token). – Daniel Dobalian Aug 04 '17 at 17:33
  • @NitinRastogi I'm not sure exactly what you're asking, but it seems like you're trying to build a .NET core web app that utilizes Azure AD. In that spirit, [here is a code sample of integrating Azure AD into an ASP.NET core Web App](https://github.com/Azure-Samples/active-directory-dotnet-webapp-webapi-openidconnect-aspnetcore). This will use Azure AD directly rather than through Azure App Services, so keep in mind it will be a bit different and turning on auth in both places will not work well. – Daniel Dobalian Aug 04 '17 at 17:38
  • @DanielDobalian: 1) Since the question is specifically about authentication, I was speaking only as it relates to authentication. Yes, there's more to OAuth overall than just an alternative to a password, but not really in this limited frame. 2) I'm speaking of the behavior of OpenID vs OAuth, again in this limited frame of reference of authenticating a user. In that sense, it doesn't matter than OpenID is built on OAuth, the difference is in where the user object exists and how it's managed. – Chris Pratt Aug 04 '17 at 17:40
  • @DanielDobalian - I am able to configure authentication both ways - through the portal only or leveraging the openid packages. My hosting is on Azure Web App. The question was - what's the difference between the two ways to configure and I think based on ChrisPratt's reply, I deduce, in case of portal only, since I don't have the necessary plumbing done, the user's contextual details in a User object is not available. With OpenId packages, that plumbing is done for me. – Nitin Rastogi Aug 04 '17 at 17:42

1 Answers1

1

Your assessment is basically correct. The portal-enabled authentication runs completely outside your application and isn't capable of setting User.Identity.Name when using .NET Core (that level of integration only works with ASP.NET 4.x).

My recommendation is to use the ASP.NET Core NuGet package so you can get the full integration. It's a lot more work to set up, but once you get it working you should be in good shape and get the full end-to-end experience you want.

If you are interested in using the portal-enabled Azure AD authentication support, then take a look at this StackOverflow question to learn how you can get it to work with User.Identity.Name.

Chris Gillum
  • 14,526
  • 5
  • 48
  • 61