Over the past three articles, I’ve covered a lot of the ins and outs of a typical Azure Mobile Apps service. I’ve covered scaffolding, authentication, and complex authorization. There are just a few more topics to cover on the basic cases.
In the last two articles, I’ve gone over how you can create a basic datasync service and add authentication to the service. What if you want to do something more complex? Authorization that is an on/off switch is reasonable as a first pass, but rarely allows you to handle the cases you actually need to implement.
In my last article, I introduced the new ASP.NET Core edition of Azure Mobile Apps, including how to set up Entity Framework Core and in-memory stores. Today, we are going to introduce simple authentication. What do you need to do to secure your entire API? We’ll cover more complex authentication schemes (such as protecting a single API, or doing DTO transforms based on the identity of the user) next time.
It’s release day for .NET 6, and I couldn’t be happier to introduce Azure Mobile Apps for ASP.NET 6 being released on the same day. When I started developing the new code-base, I had several aims:
I’ve written in the past that API keys are not security. They do not authenticate the app or user and they are easily interceptable (or extracted from distributed mobile apps). Despite that, that are good for a bunch of things, including figuring out which version of the app is being run, and ensuring that a certain version of the app you are running is using a specific backend or a specific set of policies. API keys are useful. I’m continually asked to support API keys.