Proper ADAL’s AuthenticationContext life cycle management in WebJobs long running processes.


  • Greetings,

    I have an Azure WebJob that runs in continues run mode. The main WebJob’s process can run for a long period of time, potentially, months since it runs in continues mode.

    I like to confirm the proper way of instantiating AuthenticationContext in the process.

    • Option 1: instantiate an instance of AuthenticationContext in the Main() method and use it for the duration of the WebJob process – the instance can live for few month
    • Option 2: Upon any need for an OAUTH Bearer token  instantiate an instance of AuthenticationContext and get the token

    I am thinking to use the Option 1. But I wanted to confirm my approach here.

    This question can apply to Windows Services scenarios as well.

    Thank you,

    Thursday, April 6, 2017 7:46 PM

All replies

  • Well, since you are running this in a webjob - do you need ADAL? If you use the password grant or client credentials flow it's fairly easy to do it without ADAL.

    If so you could cache the token in some other way, and just keep track of the expiry time, and request a new one when needed.

    Or is there something else that requires using ADAL?

    Thursday, April 6, 2017 8:17 PM
  • Andreas,

    Yes, I have done OATH, OATH2, etc authentication through REST calls before ADAL time. However, the simple code for that one can build  in a moderate project budget will not be close to what ADAL offers. ADAL elegantly handles specific intermittent errors on a case basis. Also, it nicely handles caching the Berear token and refresh token scenarios. With ADAL we can authentication flow with minimal code change or .  

    If you need more clarification why ADAL id relevant, please post a question and I will help you. But lets not distract this question, that seeks for proper usage pattern for ADAL. Appreciate it.

    This question stays outstanding

    Thank you,

    Friday, April 7, 2017 12:37 AM
  • I am familiar with ADAL, and why one would use it in general. There's most certainly plenty of scenarios where I would not implement my own OAuth Calls.

    But at the same time I have had use for acquiring a token in an Azure Function using the password grant flow where it was much simpler to just write a few "raw" calls instead (I didn't require the caching), so I'd argue there are valid cases for not using it as well. I don't know the details of what you are doing which is why I tried bringing up this point, but fair enough, I will assume you have a reason for using ADAL in your webjob.

    In that case I would also lean towards option 1, and put it in main. It should of course work with option 2 as well, as that is something I have tested in the past. (Off the top of my head I don't remember why we didn't stick it in main.)
    Friday, April 7, 2017 6:36 AM