Now, many of you must be wondering how the Authorization types for Azure Functions using HTTP Triggers work and where to look for information while using these different types. Hopefully, this post helps simplify each of those for you.
Now, when you create a new Azure Function from Visual Studio or from the Azure Portal, you’ll be asked about Authorization where you’ll find the selection to either be 1 of the below –
- Anonymous
- Function
- Admin
- System
Anonymous
This type of Authotization let’s you use the Azure Function without needing for any key and anyone with the URL alone can access it. Of course, this is not recommended for any production use –
- Now, if you notice your Visual Studio, when you write your first Azure Function, it comes with pre-defined method ready for you to continue to write your own code. But right away, you’ll see that the Authorization method is pre-defined considering you must’ve selected Anonymous while starting the Project.

- Also, since the Azure Function is understood to be Published already on the Azure Portal, you’ll see in the Function’s settings that the same has been reflected as well.

- Now, if you test this using Postman, the code will be able to run directly just using the URL without any API key. Either you pass in the body – and you’ll get a 200 OK with the result that the Azure Function is supposed to result.

Or using query parameters – the result will be the same.
This simply explains Anonymous authorization. Without any check on who’s supposed to access the Azure Function.
Function
In this type of Authentication, only the Function and resources associated to it will be accessible. This needs the caller to have a key [or code] to be passed while calling Azure Function –
- Let’s look at the code, and see that the type is not set to Function for Authorization.

- And when you Publish the code, the same will be reflected in the Settings too.

- And when you want to access the Azure Function from Postman, you’ll need the Function Keys defined in the Function Keys area of the Function itself – a Default Key is given already but you can choose to add your own keys and using any of them would do.

- Now, here’s what the Key looks like when you click on Show [there’s a button on the far right to expose the key’s value]

- Now, when you go to Postman, you need to can pass this as a query parameter –

Now, let’s look at the Admin Type of Authorization.
Admin
In this type of Authorization, you get access to Functions’ Runtime APIs. The way to use the Admin key is similar to the Function Keys, just that they are available from the Function App itself than the Function –
- Now, when the Authorization is set to Admin

- You’ll see this reflected in the portal once Published.

- Now, in the Function App itself – you can navigate to the App keys under Functions [as of the portal’s layout in mid-2024]

- You can expose to see this value and share it to the clients who are going to consume this Function App. They key required here is the _master

- Now, you can test this using Postman

Remember, this type of Authorization is to be used when the calling client needs to also access Functions Runtime API.
Finally, Let’s look at the System type.
System
This type of key is managed by Function runtime and is used when the calling client when there’s a need for granular access to function runtime features.
- Now, you can set this from the code and publish it.

- And it’ll appear in the settings of the Function [In case when the Function wants to access granular function runtime features].

- And this is present in the App keys area under System Keys section.

- And when you test the same, they work just like any other key from the Function app when called.

Hope this was useful!
Here are some Power Automate posts you want to check out –
- Select the item based on a key value using Filter Array in Power Automate
- Select values from an array using Select action in a Power Automate Flow
- Blocking Attachment Extensions in Dynamics 365 CRM
- Upgrade Dataverse for Teams Environment to Dataverse Environment
- Showing Sandbox or Non Production Apps in Power App mobile app
- Create a Power Apps Per User Plan Trial | Dataverse environment
- Install On-Premise Gateway from Power Automate or Power Apps | Power Platform
- Co-presence in Power Automate | Multiple users working on a Flow
- Search Rows (preview) Action in Dataverse connector in a Flow | Power Automate
- Suppress Workflow Header Information while sending back HTTP Response in a Flow | Power Automate
- Call a Flow from Canvas Power App and get back response | Power Platform
- FetchXML Aggregation in a Flow using CDS (Current Environment) connector | Power Automate
- Parsing Outputs of a List Rows action using Parse JSON in a Flow | Common Data Service (CE) connector
- Asynchronous HTTP Response from a Flow | Power Automate
- Validate JSON Schema for HTTP Request trigger in a Flow and send Response | Power Automate
- Converting JSON to XML and XML to JSON in a Flow | Power Automate