Azure Mobile Services and Asp.net Identity Architecture
I hope someone can clarify how these things can work together.
I want to be my own identity provider, so I have an OAuth token provider in my web api. I want users to register with me and then authenticate with my token provider. The idea for the future is that more of my mobile and web apps will be accessible using an OAuth login that will share the user ID.
So if I am using azure mobile services, how can I implement a regular asp.net id file? And how can a typical web application use the data stored in azure mobile services? Will I have two dbcontexts for mobile and one for web?
I have read and looked at a lot of things on azure but nothing shows how I can do this. Most of them involve the use of external providers like facebook, ms, twitter, etc. I want to be one of these external providers, just not sure how to do this and allow my sites to still use .net credentials.
If you could point me or post some example / tutorial / blogs that would be great.
source to share
This is a supported scenario, although it is not very well documented at this time.
The Mobile Services.NET runtime is built on the ASP.NET Katana Web site . The mobile service abstracts this middleware using the LoginProvider base class. The authentication model was recently made extensible for situations like yours. For mobile services to recognize and use your identity provider, you need to create your own LoginProvider.
There are currently two examples:
- Adding Katana Middleware as an Identity Provider is part of this post .
- Creating a custom username / password setting - tutorial here .
You could use these methods to wrap the standard ASP.NET authentication functionality.
As for your question about data access, there are many approaches. Your web app can handle mobile services as a backend and pass requests. This mainly applies to the web application as an additional client platform, as well as your mobile applications. Another option is to create, as you said, multiple DBC contexts. While you might get slightly better performance, it comes with code compatibility tradeoffs. It also won't scale well if you build multiple web applications on the same data server.
source to share