I'm working on an application that comprises of a C# WebAPI (on Azure Websites) and a native mobile app. Essentially, a client creates a series of messages using a Web interface and these can be browsed on the mobile app. At present, there is no restriction on this data.
A new feature requires that some clients can secure their data, so only authorized people are allowed access. We don't want to use a username/password as the overhead would be too great. Our clients could have hundreds or thousands of people who want to browse their messages.
My approach was going to be:
- User creates a service using our web portal.
- User uploads a public key into this service, which we store.
- User distributes the corresponding private key using an MDM to all devices that wish to browse the messages.
- HTTP requests for these messages require the certificate to be presented.
- The API validate the request using the public key.
There are two things that are bugging me.
We won't be using a CA to verify the cert chain. The client's certificates could be self signed. I don't see this as being a big issue since we know who our clients are.
Having the private key distributed on lots of devices could be considered a bad thing, though I believe this scenario is pretty common e.g. authenticating to MS Exchange. Responsibility for securing the private key would reside with the client.
So, to my question: Does this approach appear sound?
Additionally, Azure Websites only supports an on/off configuration of client certificates, making it impossible to mix both public and private calls. Would having two endpoints be considering good practice e.g.
It would require intelligence in the app's to know where to go, but it would make configuration of the apps much easier since they either have the client certificate or they don't.
My bonus question: Is using two endpoints a common practice?