Controlling access to Azure functions when using a consumption plan

Question

Hi,

I have been grappling with controlling access to my HTTP triggered Azure Function endpoints which are hosted on a consumption plan hence my desire to ensure that access is limited to relevant users.

So, my first batch of API's were developed and I added an API Management Service to the array of services and locked down my Azure Functions by setting them to access level Function which is great. I then added a JWT policy to my API Management Gateway and this works great as my users each have their own individual token allocated by another application, so this is perfect as I know only authorised people are actually getting at my API's and costing me money!!

However the next phase is to move all of our Service Fabric API's to Azure Functions in an attempt to minimise hosting costs as we are in a position where we deploy applications and people may not actually use the API's at all hence a consumption based Azure Function approach should reduce our hosting costs massively.

However, today I was looking at how I restrict access to my new API's that are consumed by an SPA Angular app, and whilst the majority of these API's can only be access once the user is logged in I need to expose at least 3 API's specifically Login, Password Reset Request and Password Reset to the outside world as by their very definition the user has not yet authenticated!!

I could add a function key or have a master JWT token that does not expire but this would need to be stored in the JS application which is not particularly secure.

So my question is what is to stop a malicious attacker simply spamming my public API's night and day with the end result incurring additional hosting charges?

Am I missing something here or is this just how it is?

Answer 1

In this case of public anonymous API methods, you could add a ReCaptcha validation service to both the frontend and backend. There are some "invisible" ones out there (eg. this one), meaning they don't require user interaction, but rather monitor the user behavior on the page and indicate a level of risk of the request not being from a legitimate user.

So, you can require a key provided by the ReCaptcha service as an extra header, or query string parameter on the SPA (frontend), and validate the risk by consuming the validation service on the backend (your API).

I would also make sure to add a CORS policy so that your API won't be used from unauthorized domains, that is if consumed from a browser.