TokenHelper in AppForSharePointWebToolkit fails to validate host URL with port number

[jensotto]

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

CreateAppEventClientContext should work when using ACS and nonstandard port for provider hosted add-in (like when using Visual Studio Development Server).

Observed Behavior

If using non default port for provider hosted add-in (for example VS Development Server), you will get
an AudienceUriValidationFailedException with the message: "localhost" is not the intended audience "b99d1203-1862-4c3a-9947-45663236d2ee/localhost:44349@12768036-4522-497f-833f-7ad2d7e89856" when creating an App Event Client Context (TokenHelper.CreateAppEventClientContext)

Steps to Reproduce

Create a new SharePoint provider hosted Add In project using ACS and select either SharePoint 2013 or SharePoint 2016 as the minimum version (I have not testet for SharePoint Online, but suspect the same issue there as well).
Enable Handle Add-in Installed.
Set a breakpoint on line 130 in TokenHelper.cs (inside method ReadAndValidateContextToken on the line that starts with: if (StringComparer.OrdinalIgnoreCase.Equals(token.Audience, principal)))
Debug the project.
The breakpoint will be hit and the principal does not match token.Audience because of missing port number.
Creating a token like the one in the default HomeController.cs works as expected with the port number applied.

The problem lies in that the method CreateAcsClientContextForUrl calls ReadAndValidateContextToken only including the host and not the port number.

Not sure if this is the right channel, but I get no response from contacting the AppForSharePointWebToolkit NuGet package owners (which contains the TokenHelper.cs)

Workaround is to manually modify the TokenHelper but it would be best to have this fixed in the NuGet package.

[GrahamMcMynn]

@jensotto - Thanks for your feedback. Token helper is provided as a starting point that works with the default behavior. If you have a non standard site (such as one that uses a different port), you can modify token helper to accommodate this change. It lives in your solution and is fine to be different.

[jensotto]

@mcmynn83 didn't you read my explanation? I don't have a non standard site. I'm using the default and standard developer web server provided by Visual Studio. This does not work, and it should. It works for all situations except when you try to create an app-only context. This should work as this is what is provided by Microsoft.

[jensotto]

@mcmynn83 the end result is that you can't debug a project with the current tokenhelper. Is that what you want developers to struggle with?

[jensotto]

@mcmynn83 you state that the default behaviour works, but that is NOT correct. The default behaviour requires tokenhelper to include the port number as Visual Studio Development Server uses non default ports, and it's impossible for the user to modify that. Based on that your conclusion is wrong and this issue should therefore be reopened.

[VesaJuvonen]

Let's reopen this for further investigation and proper testing also with SharePoint Online. @jensotto there are now quite a few different statements in the comments here and would appreciate following clarifications, which would speed up the possible resolution - if possible. We can surely do the end-to-end testing also on our side if needed - but getting input for following would be helpful

• In the original description, you did not mention app-only, but then mentioned following in the follow-up comment - "It works for all situations except when you try to create an app-only context". So the issue is only with app-only then?

You are 100% correct that the IIS Express is using non-standard ports and if that's an issue, we absolutely should ensure that this works properly. I did not yet test the issue personally due time constraints, but would be highly surprised if we have changed anything in this implementation since 2013 and never remember to run into this personally when doing similar development... obviously situation might have changed, just puzzled on the issue which we regardless need to investigate and potentially fix.

[jensotto]

@VesaJuvonen I could probably have been a bit clearer in the original post. You are right in that it affects the app-only context. The problematic method is the TokenHelper.CreateAcsClientContextForUrl method. This method is used in two other methods: TokenHelper.CreateRemoteEventReceiverClientContext and TokenHelper.CreateAppEventClientContext
If you use any of these two app-only context methods you will have the issue with missing port number.The reason the method does not work properly is the call to the TokenHelper.ReadAndValidateContextToken
method. This method accepts a parameter named appHostName. In the description it clearly states that this must include the port number: "(...)The URL authority, consisting of Domain Name System (DNS) host name or IP address and the port number, to use for token audience validation. (...)"
This is not done in the TokenHelper.CreateAcsClientContextForUrl method as only the host name is included due to the usage of OperationContext.Current.IncomingMessageHeaders.To.Host.

TokenHelper.ReadAndValidateContextToken is correctly used in SharePointContext.CreateSharePointContext. Here appHostName is correctly set by using the property httpRequest.Url.Authority.

In light of this I suggest changing OperationContext.Current.IncomingMessageHeaders.To.Host in TokenHelper.CreateAcsClientContextForUrl to OperationContext.Current.IncomingMessageHeaders.To.Authority