Forum Discussion

kath patterson's avatar
kath patterson
Iron Contributor
Nov 08, 2017

Getting an ADAL Access Token using an Azure Registered App from Console Prog with PnP Core

I cant believe how much time I have spent on this. Probably due to being dumb and knowing almost nothing about Azure. But the info out there in the community is so confusing with various releases of terminology and Azure admin and Pnp all mixing together into a soup of conflicting info.

 

If anyone who is more confident on this than I am can suggest what is the definitive best way to do this then I would be very grateful.

My Journey

So far, from reading ( VesaJuvonen https://blogs.msdn.microsoft.com/vesku/2016/02/15/connecting-to-sharepoint-online-from-console-application-with-adal-and-pnp-core-component/) Vesa's more recent postings I gather the best way to get an access token is to go via a registered app in Azure. He has a nice post on this but it refers to an older version of Azure admin and the have changed stuff since but it is still helpful so I started with that.

So I had a few goes at setting up an app registration in Azure. Still mystified between "native" and "web". Does it matter? when to use what? The return URI seems to be just any old url... or maybe not. Cant make any sense of that one.

Realised after a couple of hours that I had to register an API. ahah. a glimmer of light. Then had to puzzle over what API I wanted in relation to my console app. Again not clear on that. Am I getting a token for a specific API? or can I use the token for anything....

So finally had a few test registered apps to play with but no clear idea of what would work or why the settings chosen might be right or wrong. time for a beer.

 

Much later..... more reading and search GitHub for some examples (no luck)

The Azure documentation is not sympathetic to SharePoint side programmers who spend almost no time with Azure and the SharePoint documentation does not explain where to get values form in Azure and they both call the same thing something different. aaagh.

The code

setting up the code is then clear as mud. I have got the below working but I am still totally unclear about should be in the 'resource id' and I have just used guesswork (tried everything). Also the thing referred to as 'Client Id' is no longer mentioned in Azure but they have something called 'App Id'. Seems to work but I know I don't understand what is happening.

would be oh such a good video short if someone who likes SharePoint programmers could connect the Azure bit that we need to know and just walk it through. I can see we need to know how to get tokens even if we are not Azure savvy.

 

private static string GetAccessTokenForGraphAPIUsingAzureRegisteredApp(string userName,string userPassword)

{

//the registered API that we want to access is microsoft Graph against a native app

var resourceuri = "https://graph.windows.net";//not sure why this works

var NativeAzureAppId = "the app id guid from azure admin registered app";

var user = new UserCredential(userName, userPassword);

var authContext = new Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext("https://login.windows.net/common");

AuthenticationResult authResult = authContext.AcquireToken(resourceuri, NativeAzureAppId, user);

return authResult.AccessToken;

}

 

any gems of wisdom on this would be gratefully received. thanks

8 Replies

    • kath patterson's avatar
      kath patterson
      Iron Contributor

      thanks for the comments Mikael Svenson and Hunter Willis
      Mikael Svenson: in the context of writing add-ins this would make sense as the concept of app-only is well understood.
      But my quandary comes when we are writing simple one time console utilities to provision SPO we are running under the initiators credentials (the provisioner) and are required to provide an access token for a specific operation as discussed in the last SIG 2nd Nov( he says "just provide an access token"). As we are running under a credential, a certificate would not be appropriate and would be overkill for 3 lines of provisioning code.

      This seems to be where there is a disconnect between those discussing authentication for solutions where complex answers are appropriate and those of us sweating to do provisioning where we are advised to use an access token for API reasons, but the approach to do so is very unclear as the code is running under the provisioners credentials. eg https://blogs.msdn.microsoft.com/vesku/2016/02/15/connecting-to-sharepoint-online-from-console-application-with-adal-and-pnp-core-component/

      • Mikael Svenson's avatar
        Mikael Svenson
        Iron Contributor
        In that case, using an SP app registration would be the easiest route instead of adal.
  • https://docs.microsoft.com/en-us/rest/api/datacatalog/authenticate-a-client-app. Apparently you're not alone :-)

    • kath patterson's avatar
      kath patterson
      Iron Contributor

      Hunter Willis: thanks. This article is typical of the many I have read where it has many useful elements that touch on the question but is entirely written from the perspective of Azure developers with no cross over into SharePoint provisioning development where the is no 'app' and the Azure app is being used as a fake stub and has no real existence as far as I can see. Getting a joined up answer is the challenge. :)

Resources