I have a .Net 5 Web API hosted on Azure App Service.
The API has three Background services running as hosted services, which perform long running processes such as bulk emailing and SMSing, as well as other functionality that runs once a day on a timer.
I am thinking about moving out these hosted/background services into separate Azure Functions, which I would then call / trigger from my API via an HTTP request (except for the one that runs on a timer)
My concern is regarding authentication. How does that work with Azure Functions? Currently, my Web API is using Auth0 as the authentication server. So, when the user uses the front-end web app (Angular), he logs in (via Auth0's login form) and then the front-end retrieves an access/bearer token from AUth0, which it then includes in every call to the API (in an Authentication header).
Now, obviously I don't want just anyone to be able to call the Azure Functions - only my Web API should be able to do so. But how does that work? Does the API need to forward the access token it received from the front end to the Azure Function when calling it? Or is there something I need to set up in Azure Portal to tell it that my API must be allowed access to the Azure Function (and block any requests from any other origin)?
I've never used Azure Functions or even WebJobs before, so I'm a bit lost.
Thanks
When creating an HTTP-triggered Azure Function, by default it is set to have authorization level = Function, which means that any app trying to invoke that function via its URL needs to know the specific access key that is generated for that function upon creation.
In your example, your web API would store that function's invocation URL and access key in its configuration, and invoke your function with that key. Since the key remains entirely server-side on Azure, nothing else can access it, so it's completely secure.
Depending on your requirements, you can then also layer other types of authorization/authentication (e.g. bearer token) on top of the access key mechanism, or use those instead of access keys (by setting the function to allow anonymous access).
For maximum security, I would recommend using both the function access key as a first step to ensure that nobody except your apps can successfully invoke the function, and then passing along and authenticating the bearer token to ensure that the app trying to invoke that function is indeed permitted to do so.
Just be aware that Azure Functions is a slightly different beast to standard ASP.NET Core, particularly in regards to middleware which it doesn't really support yet, so you'll likely need to roll your own code for reading the bearer token from the incoming HTTP request's headers, and verifying that it's valid.
Reference: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook-trigger?tabs=csharp#authorization-keys
For this requirement, you just need to enable "Authentication/Authorization" of your function app.
Follow the steps in the screenshot above and when you click the forth red box, choose "Express" tab and click "ok" at the bottom of the page without do anything. It will create an application in your Azure AD which has same name with your function app.
After that, when you request the function app url in browser, it will ask you to login.
For more details of the steps, you can refer to this document.
Hury's guidance is best - you want to avoid using API keys on your production functions and use this just for testing. Official guidance is here:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook-trigger?tabs=in-process%2Cfunctionsv2&pivots=programming-language-csharp#secure-an-http-endpoint-in-production
Configure your Functions for AuthorizationLevel.Anonymous, and require Authentication on your Function as Hury describes. This will not only require end users to authenticate, but supports System Assigned Managed Identity when your function is called from other App Services. Less keys to vault or configure means less to steal.
Depends on what you mean by authentication.
If you just want to secure your functions you can use the authorization level = function.
However, if you need authentication with login, and you need to know the user making the request, you have to use bearer token with OpenIDConnect server.
Always use stateless authentication regardless your method.
I have developed an Azure logic app and Azure function to send actionable messages to users.
On the bottom are two buttons to reply to another logic app. If I test it on the outlook web app (O365 E3-E5 licensing), it works fine.
On the outlook desktop app it's not working with Error 401 not authenticated.
The logic app is not triggerd if I check the history logs.
Any ideas what causes the error or how to debug?
Best regards
Edit:
The Logic App uses an HTTP trigger with a specific json input.
In the Logic App the users JWT Token will be checked with an Azure Function. But, the logic app never shows an run started if I click on send in the outlook desktop app. It looks like the call is blocked by the outlook client.
I have found a solution or a workaround...
Instead of triggering the Logic App directly, the request is sent to an Azure function (which also authenticates the user). The function is just a "middleman" that forwards the request to the logic app after successful authentication.
I don't know why it doesn't work with Logic Apps in this particular version of the Outlook desktop application... but with Azure functions there is a solution :)
I have created an azure signalr service with serverless option.
The negotiate function is able to generate JWT token with 'x-ms-client-principal-name' and the connection gets established without issues.
I have referred https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-concept-serverless-development-config and the function is able to send events to a particular userid/groups.
I have been asked to secure the client - server communication.
I am new to security domain. I referred https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-tutorial-authenticate-azure-functions this link but I am not able to configure the given sample app and not able to understand the concept.
My scenario is: I have a Client .net web app in which user can login using organization account as well as using google.
This app calls azure signlar negotiate function with userID and the deviceId in which it is interested to receive events through signalR function.
Signalr function gets events from the azure eventhub trigger and sends it to the groups.
Please help me to increase the security of this application. Is the token received from negotiate function sufficient as far as security is concerned?
Can any unauthorized user connect to my azure subscribeToGroup/sendEvent functions with the acquired jwt token from negotiate?
I am trying to use this https://github.com/Azure/azure-functions-signalrservice-extension in which idToken and claimTypeList are additional parameters along with x-ms-client-principal-name(userid). But I am not able to understand this with respect to security.
The client in this sample is index.html with auth.js. But how it is said to be secure is not understandable.
Please help and direct me for the correct setup and code.
I have configured Azure Application Insight for monitoring our systems and was trying to enable the alerting. I'm using app insight availability test which provides a functionality to call a webhook URL.
I wrote a webhook using HTTP triggered Azure function, but the problem is it exposes a public URL which if called will raise an alarm on our internal alerting system. So I plan to authenticate the call to webhook.
Is there any way I can authenticate the call possibly using OAUTH.I don't want to provide the token in URL, looking for something secure. Another problem with manually using token in URL is that token rotation will require manual work.
Any suggestions on I can automate this task which will take care of secret rotation will be appreciated.
I believe token based authentication is the only possible route as of today as documented here.
But I think you should still be able to use a Function App without worrying about key rotation since the function keys can be read through the Functions API if the AzureWebJobsSecretStorageType app setting is set to files as documented here.
My question is [Similar to this one1, but with third party providers instead of active directory.
I have an end-user UWP app, and I want to consume my Azure API App. I am NOT Azure mobile app and it's client side SDK.
Most of documentation is of sort "copy paste this magic code" and never explains how authentication actually happens.
I was inspecting mobile app SDK because Microsoft's documentation says that it's auth. process is the same.
From what I see, the mobile App SDK opens a web-view very similar to that produced by a WebAuthenticationBroker. Then every request to the server is accompanied by a header X-ZUMO-AUTH and a token. It appears that this token is issued by the azure app service, not the original provider. It is much longer than the tokens issued by Twitter or Google.
At the same time when I point web-browser at the end-point and go through the log-in process, I see that the browser is using a Cookie: ARRAffinity=c4b66198677464de573103f7aa267c33ea38617020514011cea4506e0a55d9d0; AppServiceAuthSession=EIVymV
Questions:
The problem is Mobile app documentation is it just provides
instructions on how to use the SDK. I am unclear on how I would
obtain the token issued by the app service.
Everyone knows how to obtain access tokens for Google
and Twitter. Can they be used to access Azure API apps?
You are correct that API apps use the same built-in authentication as mobile apps. The basic flow looks like this:
Login to the app using provider credentials. This can be done using either a client-directed flow using your provider's SDK or can be done using a server-directed flow involving browser popups (i.e. the web view you mentioned). In the latter case, there is an endpoint at /.auth/login/ which is provided by App Service and manages the login flow for your app.
App Service will respond to your client app with a session token (a JWT).
You call into your APIs using the session token from #2. It is passed via the x-zumo-auth HTTP request header (it's named this way for legacy reasons).
The AppServiceAuthSession cookie you are seeing is the session cookie for when you use a browser to do authentication. ARRAffinity is an internal routing cookie used by App Service and is not related to auth.
If you're looking for more internal technical details on how the built-in App Service Authentication / Authorization works, check out my blog, starting with this post: http://cgillum.tech/2016/02/01/architecture-of-azure-app-service-authentication-authorization/