locked
OAuth with Azure Active Directory in VS2019 Debug Environment RRS feed

  • Question

  • User1205965688 posted

    Ok.  I've exhausted my Google-Fu and can't find anyone or any post that references my issue.  I'll try to explain the best I can.  If this has been posted or asked about previously, forgive me.  

    I have an .NET 4.7.1 application that I'm migrating from on-premise to Azure's web app services and bumping it up to .NET 4.7.2.  The previous version uses windows authentication and I'm moving it to OAuth with our AD tenant in Azure.  When I run the app in VS2019 with the debug tool, OAuth is completely skipped.  If I deploy the app to Azure, OAuth is launched and authentication acts as it should.  

    In my app registration in Azure, I have the proper RedirectUri's setup to point back to my localhost.  I have another app I've setup in the exact same way and the authentication process works just as it should in both VS2019 and in Azure.

    Has anyone ever experienced this behavior with their apps?  It's not stopping development, but it sure is annoying having to deploy the code every time I want to see if a code change is working as expected.  I realize, this post is void of code and other things some people might expect here, but I'm just trying to see if anyone has had the same experience and if they have been able to resolve this issue while debugging in VS.

    Anyone?  Beuller? 

    Wednesday, November 4, 2020 6:07 PM

All replies

  • User475983607 posted

    What is skipped the login?  That might be the case if you already have the auth cookie.  Just delete the cookie and that should redirect you to login etc.

    Wednesday, November 4, 2020 7:04 PM
  • User1205965688 posted

    I don’t believe it is cookie related as I’ve cleared the cookies many times and still get the same behavior. Even so, with the cookie in place, I can watch the oauth redirect take place when I run the app from azure. When I run the app from VS, the redirect does not occur at all. I’m less concerned at the moment with the actual login prompt. If the redirect doesn’t take place, there is no chance to login. 

    In azure, the redirect takes place and you get the login prompt. Not so in VS. 

    Friday, November 6, 2020 1:12 AM
  • User475983607 posted

    A standard web applications setup uses an authentication cookie to cache user claims/roles after a successful login.  Azure also stores a cookie on the user's machine after a successful login.  If either cookie exists, then the use is not redirected to the login.

    If all cookies are deleted and the user can access secured web site resources then there is a problem with the security design.

    Friday, November 6, 2020 12:29 PM
  • User1205965688 posted

    I appreciate you taking the time to respond here.  I do understand how the cookies work for the web application.  I don't feel like though that you are fully grasping the nature of my situation and perhaps I'm not explaining it well.  If I'm misstating anything below, please correct me.  I'm still learning this stuff anyway.

    Even if the cookie exists, the application still needs to obtain a token to access the application's resources that have the [Authorize] attribute applied at some level in a controller correct?  In order to obtain the token, the application redirects the authorization request to https://login.microsoftoneline.com/<tenantID>/v2.0.  Once the user is verified by either the user giving credentials or by looking at the cached credentials in the cookie, the token is passed back to the client browser via the RedirectUri supplied in the app registration that matches the original URL request from the browser.  In VS debugging, it's https://localhost:<port#>.

    In VS2019, the request to obtain the token by redirecting to microsoftonline.com to obtain the token never happens and the claims data is never retrieved.  If you deploy the exact same code to Azure and access the website via it azurewebsite.net URL, the redirect to microsoftonline.com occurs, the token is received, and claims data is obtained.

    Hope this helps a bit.  Again thanks for taking time to think about this stuff.  It's really mind boggling when the exact same design works flawlessly in another application.

    Friday, November 6, 2020 4:46 PM
  • User475983607 posted

    Even if the cookie exists, the application still needs to obtain a token to access the application's resources that have the [Authorize] attribute applied at some level in a controller correct?

    No. The user claims are cached in the auth cookie after a successful login.  The auth cookie framework reads the auth cookie contents and using the data to build a Principal.  The  Principal drive the [Authorize] attribute in the web application.

    In VS2019, the request to obtain the token by redirecting to microsoftonline.com to obtain the token never happens and the claims data is never retrieved.  If you deploy the exact same code to Azure and access the website via it azurewebsite.net URL, the redirect to microsoftonline.com occurs, the token is received, and claims data is obtained.

    The local application has a separate registration.  Perhaps that's the problem?  Generally there's an error when the registration does not match.

     

    Friday, November 6, 2020 5:34 PM
  • User1205965688 posted

    Fair enough.  I'm going to add a couple of url's to the RedirectUri section in the app registration.  Perhaps we need to add a level or two like https://localhost:<port>/home/ or something like this.  Thanks for the insight.

    Friday, November 6, 2020 5:39 PM