Authentication : ADAL
Updated: Aug 21, 2019
ADAL (Active Directory Authentication Library), it is a .net authentication library that is used to authorize users against AAD (Azure Active Directory). Now this is important, as it makes sure that only people with a certain set of permissions can use your Function Apps. Which is very important if your apps are doing something very... sensitive. It is also good practice to lock everything that you can down with authentication. So... it's as well you learn about it now as in a while, we'll be seeing an actual example of how something like this would work in the real world. It's worth noting that ADAL is a front-end library. In the back-end to get tokens, we have to do it the old fashioned way, sometimes. Again in the future you'll see this probably in a sample under the Azure section.
Basically when you are trying to access resources you need an access token (JWT). This is a string that defines the user and the permissions that the user has consented to. It also contains info on who are they and what can they do. Fyi, ADAL can be used to get tokens for both on-premises and cloud solutions.
The main features of ADAL are:
. Token refreshing - gets a new token before the current token's expiry has elapsed
. Storage into "in memory token cache" - stores the token securely client side
. Acquire a token async - can get a token asynchronously
. Manages the process of acquiring a token - no messing around with oAuth flows
The big question is how does it work. I'm tempted to say auto-magically. The process is actually relatively straight forward. Call the "AuthenticationContext" to acquire a token, and pass in the required resource, client id, redirect uri and platform parameters. It's a async call as well. Woop, woop! In the background whats happening is the authorization authority is checking to see if the user has permission to use an auth app defined (client id). Then it sends the token back to a specific uri, from where the token can be accessed and consumed. Or put more simply:
In conclusion, lock everything down with authentication where you can. And only have the user consent to permissions that they actually require. There is nothing scarier to a user than a long list of permissions. Especially if you don't make use of them or they don't logically fit in with your application.
If you need extra reading material related to ADAL, I've placed it below in a handy bullet-list:
Hope this explanation helps!