Forum Discussion
How does the Sharepoint phone App handle redirects?
Hello community!
I'm an F5 load-balancer engineer that has stumbled upon an issue revolving the Sharepoint App. My customer uses their F5 ADC for many different things including authentication proxy where some requests are directed to EntraID for MFA and other functionalities using SAML.
The customer is using Sharepoint and for one particular link which is posted on sharepoint, directs the users to the application published on the F5. The F5 requires the users to login so it is immediately hits a SAML redirect to EntraID.
For users sitting on a laptop/desktop browser OR phone users in the local browser, this works fine. However, for anyone sitting on the Sharepoint app, this immediately fails when the redirect is sent to Entra. My guess is that it cannot handle the redirect that my F5 is sending it OR it cannot store the cookies required when the session is being created on the F5.
So to my questions:
How does the Sharepoint app handle redirects?
How does it handle storing cookies?
What is the usual way of handling links of this nature? I have tried reading up on some details but I know too little about Sharepoint for it to make sense.
I wanted to set this up in a lab and was looking for a trial but it seems that I cannot have a 30-day trial when located in Sweden.
One solution I thought of was to hit the Sharepoint app with a 401 response and grab the Kerberos ticket and authenticate using that but that requires some more komplex configurations like creating a kerberos keytab file which according to our AD guy, requires us to take over the SPN and I'm worried that will break more than it will fix.
All help here is much appreciated as I have kind of hit a stand-still.
Hey Pilen!
I totally get where you're coming from with this issue, it’s one of those classic "works everywhere except in the app" situations. I’ve pulled together some resources that should help you dive deeper into how the SharePoint app handles redirects, cookies, and how SAML flows work with F5 and Entra ID. Hopefully, these give you some more insight into what’s going wrong.
Helpful Resources to Check Out:
F5 Bug Tracker – SAML Issues with SharePoint
There’s an issue documented where SAML redirects fail when SharePoint is accessed through F5’s portal. It sounds like it could be pretty relevant to your setup:
→ https://cdn.f5.com/product/bugtracker/ID551225.html
Stack Overflow Discussion: Redirects and Cookies in WebView
This thread talks about WebViews (the thing SharePoint’s mobile app uses) and how they sometimes fail to handle 302 redirects and cookies properly. Could be exactly why the redirect isn’t working in your case:
→ https://stackoverflow.com/questions/44576468/when-redirect-with-code-302-wkwebview-cannot-set-cookieHope this helps!
Hello Ebol19
Thank you so much for your reply.
First off the BugID I'm afraid does not match. We are using a newer version and this is when you open SharePoint through F5 itself. In our case the sharepoint app is simply redirecting us to an external resource that happens to be behind an F5 device with a SAML Auth Agent with Microsoft EntraID as the IdP.
The other link was kind of interesting though. It led me to some new thoughts and resources that might be able to handle this. With the help of ChatGPT it suggested that it might a problem handling a 302 and a 303 might be better. So perhaps I can send that back instead or I can perhaps trigger the Sharepoint app to open the resource in local browser instead.
Is that something I can do on the Sharepoint side? Create links that opens "outside" of the app by the default browser? Because I believe that would be an acceptable solution for the customer and they just need to swap back to the app when they are done using that application.
I have a few alternatives to select from on the F5 but having native support from the app would be a safer bet.
Thanks again so far for the assistance!
