Great sample, but hard to follow

I have successfully made the sample working from the provided description and I see this project is also referenced in many other cases.

But there are several greater issues at hand.

1. I think the MVC model sample is lacking comments and versatility.
2. A clear flow of operation is hard to follow due to "magic" and unexplained middle-ware handling and a tight coupling with the OWIN architecture. Keep in mind, there are developers in dire need of replacing their former EWS (Exchange Web Service) authentication due to end-of-life at 13. Oct 2020.
3. the sample doesn't distinguish clearly between authentication of the user and the daemon access grants - there is an overlap between the tenant provided by the login-user and the admin-account needed to grant access to the AD users. A stack-exchange post helped me to solve how to provide the tenant ID for an Exchange domain (Try access https://login.microsoftonline.com/{domain}/.well-known/openid-configuration ), but let's say I just need the grant from within a standard webforms application? This project is heavily relying on the OMC framework and therefor hardly serves as a clear daemon app example for thousands of developers out there?

[jmprieur]

Thanks for the feedback @ThomasTWilliams
You also the https://github.com/azure-samples/active-directory-dotnetcore-daemon-v2, which is more pure.

I have checked out the samples, but I still think this sample here is more close to my use case.

Consider this, I have a webapp, with many different end-users. Some of them needs to synchronize data from an Azure AD on an ongoing basis. To do this, they need to create a synchronization profile (and they can have more than one). Within the profile I would like the user to sign-in the administrative user to grant access to their tenant. A service is then taking over the actual synchronization by using the provided token. I may even use several backup services. When or if the user wishes to withdraw the grant, the service immediately halts.

This scenario is done today by users providing O365 service accounts configured for impersonation, a task usually quite heavy for end-users to understand. The sample here is almost doing what I need, and I am currently getting a bit of help studying the OpenID Connect protocol (more specifically https://docs.microsoft.com/da-dk/azure/active-directory/develop/v2-protocols-oidc )

If I understand the sample correctly, what I need is to store and secure the JWT token and use it from within the service to access Graph API?

[TiagoBrenck]

Hi @ThomasTWilliams we are still validating this background worker sharing the cache scenario, so we can build a sample for it.
Could you confirm if what are you looking for is something similar to this: https://github.com/TiagoBrenck/BackgroundCacheRenew ?

Hi @TiagoBrenck, thanks for your help and commitment, I'm am checking out the sample and I will return.

EDIT: It seems like the wide use of dependency injection along with middleware still blurs the understanding of the underlying transactions for me as I'm an old school 3-layer model WYSIWYG developer, so analyzing the fine-prints take time.

In the sample you mentioned, I find it very useful to see how persistence is implemented through TokenCache and the daemon app is fairly easy to understand although I wish the AcquireTokenSilent methods was better documented. For now, I have studied various docs on the use of OpenIDConnect and so far I have managed to get some samples working with plain old requests, to better understand the flow, but I still have some tasks ahead of me, keying these properties together.