In a past article, we looked at Serverless compute in Azure in general and Azure Functions specifically.
Let’s look at each of those authorization level.
Anonymous means no authentication is required. Any valid HTTP request passes.
Function, Admin & System authorization level are key based.
The online documentation has a good section on authorization keys.
Basically, there are two types of keys: host and function keys. The former is scoped at the function app level while the latter is scoped at the function level (i.e. within a function app).
There is a special host key called the master key (aptly named _master). A master key is always present and can’t be revoked although it can be renewed, i.e. its value can be changed and its older value won’t be accepted anymore.
Keys can be managed in the portal using the Manage sub menu. Although the context is function specific, we can edit the host keys there too.
A key can be passed to an Azure Function HTTP request in the URL as the code query string. Alternatively, it can be included in the x-functions-key HTTP header. Only the key value, not its name, is passed.
Function authorization level requires a key for authorization. Both function and host key will work. In that sense it is the less restrictive of key-based authorization level.
Admin authorization level requires a host key for authorization.
Passing a function key will fail authorization and return an HTTP 401 – Unauthorized error code.
System authorization level requires the master key of a function app for authorization.
Passing a function key or a host key (except the master key) will fail authorization and return an HTTP 401 – Unauthorized error code.
User authorization level isn’t key based. Instead it does mandate a valid authentication token.
As of this writing, i.e. early December 2017, it isn’t fully implemented. We can follow the feature status with this GitHub issue (the issue refers to easy-auth which is based on Azure Active Directory).
There are compelling reasons to use a token-based authentication system instead of system-key one. We will come back to those in a future article.
Azure Functions supports multiple Authorization levels for HTTP requests. The level can easily be changed by the function.json specification file.
Using those configurations allows the function runtime engine to take care of authorization logic and freeing the function code from that logic.
Update (23-04-2019): I would recommend you take a look at my colleague Matt Ruma’s blog, Secure an Azure Function App with Azure Active Directory, for more details on AAD protecting a function.