I am going to develop a mobile app, its bit of social kind of app.
For data, I am planning to use Azure SQL for hierarchical data and Azure Storage for images etc.
Now for user authentication, I want my users to log in using oAuth providers such as Facebook/google/live etc rather than developing a user authentication of my own.
So for oAuth, I am planning to use Azure Mobile Services.
The thing I am not clear is after I authenticate user using Mobile Services, how I go to query the user's data that is in Azure SQL . Should I use the APIs that I can write in Node.js from Mobile Services or should I develop a WebAPI project to talk to data.
Using Mobile Service's node.js API looks easy and simplest way, but the apprehension I have with querying data from Mobile Service is it allows to query the tables that are in its own schema. If I wish to have some tables in some other logical schema, I won't be able to query it from Mobile services. Is my understanding correct here?
.net WEBAPI will be my preferred way of talking to database,but if I write a WebAPI, how do I get user's Identity carried from Mobile Services to WebAPI.
if someone can point me to some example/sample of using using Web API and Mobile Services together, will appreciate
thanks in advance.
Mobile Services would allow you to access table's outside of its schema, although it is more work. You can use the MSSQL object to talk to additional schemas. See: http://www.windowsazure.com/en-us/documentation/articles/mobile-services-how-to-use-server-scripts/#TSQL
The new .NET runtime, currently in preview, also has support for using multiple data sources.
I would keep azure mobile services for authentication. You can then create your full schema in SQL where your user is nothing more than the userid from mobile services.
In code you end up with this user id after authentication. From that point forward everything is in SQL.
Related
I was wondering how I could connect a mobile app created in ionic to azure, the app needs to interact with Dynamics CRM where all the data is. My guess is that I have to login via Azure AD , get the token, create API endpoints in Azure ( which service? ) or expose them, nd query the endpoint with the token.
Is this the right workflow?
thanx in advance
You're pretty much on the right track. You can host your API in an Azure App Service. You can also secure it by integrating Azure AD with your app service using your token. This tutorial walks through using a front-end and back-end app and securing communication with it. Since your already have a front-end, you can ignore those steps. Although the same is a .NET Core application, the same applies if you were to write your API in NodeJS or another language.
Hope this helps.
I am designing an application that will consist of:
SPA written in React, deployed to an instance of Azure App Service
REST API written in .Net Core Web API, deployed to another instance of Azure App Service
Azure SQL Database in the same Azure tenant as the app services above
All these resources will be connected to the same instance of Azure AD (also in the same tenant).
Conceptually, I suppose the authentication could work roughly like this:
The user connection to the SPA and obtains an auth token
The token would then be passed to the API and then the API will use that token to authenticate the user to the SQL Database (this seems possible)
However, I have not been able to find any walkthroughs or other documentation that would demonstrate this seemingly straightforward way of implementing authentication. Seems like this is a typical enough scenario for it to be widely documented by bloggers or Microsoft itself, so not being able to find it makes me wonder if I am not thinking about this right, or maybe I am not looking in the right places.
Can someone please help me figure out what is the right way to approach this and point me to some online resources that could guide me through this?
Thank you!
It's much more common for the REST API to use its Managed Service Identity to obtain a token for Azure SQL Database, and use that. It's always been rare for web apps to use the browser user's identity to connect to SQL Server.
See, eg: Tutorial: Secure Azure SQL Database connection from App Service using a managed identity
Hi I am planning to move my SharePoint Application database from SharePoint List to SQL Azure. I am planning to create an API for that so I could Access my Data using Angular to that API. But I have a question is there a way to make sure that the API I will be create can and only be access inside my O365 SharePoint? Is there a way to build some kind of trust or authentication? What are the security features I could use to make my data safe
Yes there are bunch of security features like:
Securing APIs with key, JSON Web Token (JWT) validation, and IP filtering.
I think you could use IP Filtering for your scenario.
I am trying to create an app in Xamarin.Forms which can store photos and their description and names. In this app, there will be users and image loading will depends on account with what you signed in. I store images in storage accounts and its urls I store in Azure Easy Tables.
I want to ask that for saving names and descriptions I should use Azure Easy Tables or other Azure storage feature ? If I should use Easy Tables how can I load only specific data for specific user?
Thanks for your answers !!!
According to your description, I assumed that you are using Azure Mobile Apps for your mobile app backend. You could leverage Azure Mobile Apps server SDK to store related data which is stored under blob storage / file shares.
I want to ask that for saving names and descriptions I should use Azure Easy Tables or other Azure storage feature ? If I should use Easy Tables how can I load only specific data for specific user?
Azure Mobile Apps support two backend languages (C#,Node.js). For C# backend, you could follow the tutorials below to implement your requirement.
C# backend & Xamarin.Forms projects
App Service Mobile sample todo list client app with images
Connect to Azure Storage in your Xamarin.Forms app
Easy Tables are served by Node.js backend. For Node.js backend, Azure Mobile Apps have not provided the similar File Management server SDK as C# backend. Details, you could follow 30 DAYS OF AZURE MOBILE APPS.
For associating data with the specific user, you could follow adrian hall's book about Data Projection and Queries for C# backend, 30 DAYS OF ZUMO.V2 (AZURE MOBILE APPS): DAY 6 – PERSONAL TABLES for Node.js backend.
We plan to use Windows Azure Mobile Services for several of our commercial apps and would like to create a single data store for users instead of creating it for every mobile service. We don't want to use Microsoft or Facebook... providers due to this issue Multiple apps using a single Azure Mobile Service for Live Authentication?
This way, the user data for all our apps is stored in single separate Custom_Auth database and the users won't need to Register again for our other apps. Should we create a separate mobile service that basically enables custom authentication and acts as a provider for other apps?
Do you see any pitfalls with this approach and what steps would I need to take for creating this custom provider as a separate mobile service?
Basically, we want to create our own provider so that user of one our apps can login to the other apps using the same credentials.
I have read through the following links. Posting them here as they may be useful for others starting out with Authentication and Azure Mobile Services.
http://www.thejoyofcode.com/Generating_your_own_ZUMO_auth_token_Day_8_.aspx
http://www.thejoyofcode.com/Fetching_a_basic_user_profile_in_Mobile_Services_Day_9_.aspx
http://www.thejoyofcode.com/Exploring_custom_identity_in_Mobile_Services_Day_12_.aspx
http://chrisrisner.com/Authentication-with-Windows-Azure-Mobile-Services
Thanks in advance
Hope this helps you
http://chrisrisner.com/Authentication-with-iOS-and-Windows-Azure-Mobile-Services
Someone created a custom authentication API using AZURE
with Parse.com, you are limited to their backend and unfortunately it doesn't have all the nice features as Azure
MS really messed us around with this