Azure App Service Authentication - Pulled data even when authentication failed

Question

I have a Xamarin Forms application that is targeting Windows UWP. I have successfully setup Offline Sync and Authentication by following the Microsoft docs such as this article: https://docs.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-windows-store-dotnet-get-started-users

I have also successfully setup a background (out-of-process) task to run using a Windows Universal Runtime Component.

The process flows as: 1) User runs the application for the first time, they must login and authenticate to Active Directory. The application then caches their token and registers the background task.

2) The background task kicks off on a Timer. During testing, I did NOT have it refreshing the token because I wanted to test the 1-hour token expiration and refresh process.

In my testing, I discovered two things that I am not completely understanding and which I found odd (not behaving as I expected).

1) When I examine the expiration date of the token the user receives upon first login, the expiration date is set for 30 days in the future. I thought it was supposed to expire after 1 hour. Why does it show 30 day expiration date? (This isn't too big of a concern as I did confirm that it does stop allowing access after an hour, just an oddity that I am observing).

2) This is the one I have a concern about. Even though the background task was not able to authenticate after the 1-hour period, it still was able to pull data from Azure to the device. The push data sync failed because authentication failed, but the pull data sync succeeded. This is concerning because I do not want unauthorized attempts to be able to pull data. Has anyone else ran into this? Is this a bug? Did I configure authentication incorrectly somehow?

My Settings:

Azure App Service > Easy Tables (Node.js backend) has all permissions set to "Authenticated Access only".

Azure App Service > Settings > Authentication/Authorization >

• App Service Authentication is set to On,
• Action to take when request is not authenticated is set to Log in with Azure Active Directory,
• Authentication Providers is set Configured for Azure Active Directory.

Mobile App Code:

MobileServiceClient client;
IMobileServiceSyncTable<TableToPull> tableToPullDataFrom;
IMobileServiceSyncTable<TableToPush> tableToPushDataTo;
this.client = new MobileServiceClient(Constants.ApplicationURL);
this.client.CurrentUser = new MobileServiceUser(Settings.UserId);
this.client.CurrentUser.MobileServiceAuthenticationToken = Settings.AuthToken;
store.DefineTable<TableToPull>();
store.DefineTable<TableToPush>();

The Push Async Code is (which fails when authentication fails, as expected):

await this.client.SyncContext.PushAsync();

The Pull Async Code, which should fail when authentication fails but did not (this is my concern) is:

await this.tableToPullDataFrom.PullAsync("tableQuery",this.tableToPullDataFrom.CreateQuery());

I am concerned that the background task was able to pull data from Azure even though authentication failed. I am hopeful that I am misunderstanding this concept in some way and someone can explain to me why this happens? Or if I need to configure something differently? I need to make sure unauthorized logins cannot pull data.

The background task attempts to push and pull data in sequence and I can see that it fails due to invalid authentication during the push task but then succeeds during the pull task. I can also verify this because the pull task does grab updated data from the SQL Azure DB (I can view it using Isolated Storage Explorer and SQLite Browser) but it doesn't send changed data to the SQL Azure DB (viewed in SSMS).

Answer 1

The "action to take when authentication fails" is wrong. You need to set it to "No action". This is so that the authentication can be handled by your code.

If you are using Easy Tables, adjust the permissions on the table to "Authenticated". If you are using ASP.NET, add the [Authorize] attribute to your class.

Authentication is covered in depth in my book - chapter 2 of http://aka.ms/zumobook .