Does DurableHttpRequest support custom OAuth 2 apis?

[andybooth]

Is it possible or is there a recommended approach/sample to make a DurableHttpRequest against a custom OAuth 2 authenticated resource, rather than a Managed Service Indentity protected resource? Perhaps using a custom TokenSource or IDurableHttpMessageHandlerFactory? Which approach may work best with the DI/config of Durable Functions? In my case I want to use the same admin clientid/clientsecret combination using client credentials flow for all durable http requests in the app.

Many thanks.

[cgillum]

I think using a custom ITokenSource implementation is the right way to go about this. We don't have a sample for OAuth 2 specifically, but you can refer to our token source unit tests to get an idea of what it might take.

Making it available through DI should work. We generally advise against using DI objects in orchestrator functions since they're technically non-deterministic, but I think injecting an ITokenSource implementation should be fine since it's used primarily in the context of a built-in activity function.

Feel free to submit a GitHub issue (or even better, a PR) if you think we should have a built-in ITokenSource implementation for a client credentials-based flow. I think this would be a useful feature to have.

[ConnorMcMahon]

One key thing to make sure about your custom ITokenSource implementation is that it is serializable. That means you may be better off saving your client id and secret as environment variables, and instantiating your MSAL class instances dynamically (maybe with a static Lazy variable to only instantiate it once per machine?).

Here is some MSAL code to generate access tokens with a client credential flow. You could largely move the implementation up through result = await app.AcquireTokenForClient(scopes).ExecuteAsync(); into your ITokenSource.GetTokenAsync() implementation. You just need to replace the code for how you get your client id and client secret.

NOTE: If you are using the App Service Authentication feature, we populate a client id under the environment variable WEBSITE_AUTH_CLIENT_ID, and then the client secret is populated in an app setting under your control (or if you used the legacy configuration experience, under the environment variable WEBSITE_AUTH_CLIENT_SECRET).

[andybooth]

Many thanks both for the pointers on ITokenSource. (I would love to Mark As Answered but Github isn't allowing me to, giving an auth error!)