0

I am working on a provider-hosted app that uses high-trust S2S authorization (please pardon me if my terminology isn't quite right) to access SharePoint on the user's behalf.

In my test environment, I've found that this works well when the user opens the app from Site Contents, but if they navigate directly to the app (e.g. by going to its URL in a fresh incognito browser window), it seems that communication between the app and SharePoint fails. The auth token is not accepted by SharePoint, and the attempt to query SharePoint ultimately fails with a 403 error.

Looking at the ULS logs, it looks like things start to go awry about this point in the request from my app to SharePoint:

01/02/2019 06:23:39.65  w3wp.exe (0x4EB4)   0x6244  SharePoint Foundation   Claims Authentication   ajrho   Monitorable security token '0e.t|----|me@mydomain.com687bb741-e682-48b6-b72e-6575d11a7d11_Default' is found in the local cache, but it is expired. Returing Null..  fa11b29e-5847-40c4-86b7-eb4646643db2
01/02/2019 06:23:39.65  w3wp.exe (0x4EB4)   0x6244  SharePoint Foundation   Application Authentication  ajwp0   Medium  SPApplicationAuthenticationModule: User token does not exist in token cache.    fa11b29e-5847-40c4-86b7-eb4646643db2

If I then just log into SharePoint, go back to the browser tab where I was trying to use the app, and refresh the tab, then everything works, and instead of the above, the ULS logs show something along this nature:

01/02/2019 06:27:36.73  w3wp.exe (0x4EB4)   0x313C  SharePoint Foundation   Application Authentication  ajwpw   Medium  SPApplicationAuthenticationModule: Attached actor identity to current thread. Actor Identity:0i.t|ms.sp.ext|f211d2dc-c1a6-421e-a9b3-c5811fe686dc@6331799e-6148-4554-a694-7d6783098c44.  3412b29e-1829-40c4-86b7-e2cdf5c17d0b
01/02/2019 06:27:36.73  w3wp.exe (0x4EB4)   0x313C  SharePoint Foundation   Application Authentication  ahkpt   Medium  SPApplicationAuthenticationModule Authentication finished successfully for user:0e.t|-----|me@mydomain.com and actor:   3412b29e-1829-40c4-86b7-e2cdf5c17d0b

I find this puzzling because I would have thought the S2S model would allow the app to act on the user's behalf even if they hadn't actually accessed SharePoint in the last few minutes, but it seems that this doesn't work.

Is it possible that there's something wrong with my configuration, or with the way I am generating the access tokens, and if so, how can I troubleshoot it? FWIW, I'm currently attempting this with both SharePoint and my app authenticating the user with ADFS (using something like what's described here), but I have witnessed the same problem when both SharePoint and the app are set up to use Windows authentication backed by AD.

  • Do you use APS.NET MVC with SharePointContextFilter attribute? – Sergei Sergeev Jan 2 at 15:40
  • @SergeiSergeev Yes. I've made some modifications to the filter class in order to accommodate some parts of my particular scenario, but for all intents and purposes, that's what I'm using. – JLRishe Jan 2 at 15:45
  • When you do experiments using incongnito tab, do you copy full url to your web app with full query string, i.e. /?SPHostUrl=.... etc.? In other words the same url as after redirection from Site Contents page? – Sergei Sergeev Jan 2 at 15:56
  • @SergeiSergeev Yes, exactly the same URL. And if I refresh that URL after signing into SharePoint in a separate tab, the authorization works. – JLRishe Jan 2 at 16:05
  • That's strange... as far as I remember it should work in incognito without issues. – Sergei Sergeev Jan 2 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.