locked
Restarting Azure App Service on Linux with Azure Active Directory authentication resets /.auth/me/ RRS feed

  • Question

  • I'm using Azure App Services Authentication/Authorization to restrict access to my web app, using Azure Active Directory as sign in method.

    I've set the "Action to take when request is not authenticated" to "Log in with Azure Active Directory".

    In order to find details about the logged in user, I make a request to the /.auth/me endpoint (as instructions from Microsoft docs says). This works fine, until the app is restarted in Azure. After restart, the /.auth/me/ endpoint returns an empty array, instead of the user information.

    I can only reproduce the problem if the App service plan is running Linux. If I create a Windows App Service Plan, the /.auth/me endpoint is populated even after restart.

    I've tried creating a new app on Azure, without uploading any code, and the problem is still there.

    Do I need to set some extra settings in order for this to work on a Linux based ASP? I've tested with both docker based ASPs and code based (on dotnet core 2.2).

    Monday, September 2, 2019 2:45 PM

Answers

All replies

  • Hi,

    The explanation is that after the restart the Middleware Container (which handles Auth for Linux) is getting spawned again and docker containers are not persistent by nature so any user data  would be wiped away after a restart.

    Hope this helps.

    Tuesday, September 3, 2019 2:22 PM
  • Is the Middleware Container present even if I don't use docker for my own code? Because the problem exists even if I deploy a "normal" code project.

    Even so, the session is only half gone. I can still access the site but /.auth/me returns an empty array. If the auth container is reset, shouldn't I be forced to sign in again?

    Regards,
    Kristian

    Wednesday, September 4, 2019 6:40 AM
  • Hi Kristian,

    We are investigating this as a potential bug.

    In the meantime, please try using our blob storage token store: 

    This in general is our preferred method for the token store.
    File systems (especially on Windows) can be rather fragile, so blob backed storage should be far more reliable.
    ​It does have some cost though, but it should be fairly minimal (just general Azure Storage costs).

    Wednesday, September 4, 2019 4:49 PM
  • Thank you!

    I had to increase the access in my SAS to get it to work, compared to the blog post you linked, but otherwise it worked fine. The permissions I used:

    • Allowed services: Blobs
    • Allowed resource types: Container, Object
    • Allowed permissions: Read, Write, List, Create
    Thursday, September 5, 2019 12:38 PM