none
What is the recommended solution for implementing the OAUTH 2.0 flow in sandboxed app for office. RRS feed

  • Question

  • Hi, 

    I had troubles implementing the OAUTH 2.0 flow in app for office.

    See my interventions on this Yammer discussion. The issue that I have created in the Adal.js library. 

    I created a related thread regarding the precise security restrictions in app for office. It was asked to create a new thread dedicated on the OAUTH flow and here it is.

    I have a working solution and I would like to submit to you to see if this can be considered a long-lasting solution. The basic idea to overcome the CrossOrigin restrictions is to perform the OAUTH flow in a popup. It looks like that popup are not restricted by CrossOrigin policies. When the flow is completed we give the callback url hash to the main sandboxed iframe, so it may recover the necessary info to performed allowed request to the external APIs. Therefore, those calls are not restricted by Cross Origin request and works fine, why is that ?

    The image below summarizes the flow that I have implemented.

    In my blog, I have created an article on the subject with more details. Please have a look here.

    So my questions are:

    1) why calling APIs after OAUTH flow is allowed while other cross domains request are prevented ?

    2) Does the flow presented here is OK? Can it be considered as the proper way to implement OAUTH2.0 in the context of app for office ?

    Thank you

    Benoit

    Thursday, May 28, 2015 3:44 PM

All replies

  • Hi Benoit P,

    Thank you for posting in the MSDN Forum.
     
    I'm trying to involve some senior engineers into this issue and it will take some time. Your patience will be greatly appreciated.
     
    Sorry for any inconvenience and have a nice day!
     
    Regards & Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, June 1, 2015 9:29 AM
    Moderator
  • Hi,

    Thanks for sharing your workaround. I did some investigation on the desktop and iframe sandbox of Apps for Office.

    Assume the Web Browser is IE, for a normal web application, the pop-up window should be in the same process of the parent window with the same integrity (L-integrity), and they can share the cookie for the same domain. In the desktop sandbox model, the popup window is opened in another IE process with a different integrity level (M-integrity), and they do not share the cookie, that’s why the token in the pop-up window could not pass back to the parent window though the cookie or session storage (In your blog, you workaround it with window.oauthHash).

    From the web application development perspective, there are usually 2 ways to get the token from resource server to client web application (page navigation and popup window).

    The page navigation works in the desktop sandbox environment (no need to pass the value between pop up window and parent window).

    The pop-up window works in the iframe sandbox environment (no need to change the domain of the iframe).

    Currently, I have not figured out a recommended universal way to work on both side. I will try to consult some other engineers who are familiar with this topic and come back to post if I have any updates.

    Regards,

    Jeffrey


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Monday, June 1, 2015 9:43 AM
    Moderator
  • Thank you very much!

    I am waiting for more feedback and hopefully a 'recommended' way for the oauth flow. This is important matter to me and for others I suppose as long as app for office will often deal with connected services.

    Sincerly

    Tuesday, June 2, 2015 7:45 AM
  • Any news about this?

    I was able to resolve the issue adding the oauth login urls to the "App Domains" in the office app.

    But when the OAuth is a custom client STS then it will fail and a authentication popup will show that blocks the app. 

    Thanks

    Wednesday, September 23, 2015 6:12 PM
  • Any updates I am also looking for some better way to handle oauth login. I am running in same issue that Benoit P explained.
    Friday, October 30, 2015 10:19 AM
  • I am running into the same issue using Google OAuth in Outlook 365 Addin devlopment. Any updates on this would be useful.

    Thanks

    Monday, November 23, 2015 11:00 AM
  • Same problem here!
    Thursday, December 10, 2015 1:38 PM
  • Any news on this ?

    Most of the OAUTH sign in url cannot be iframed so popup is the only solution. But we still have the problem with the desktop client.

    Wednesday, December 16, 2015 12:56 PM
  • A working approach with the desktop client is the one explained here

    http://blogs.msdn.com/b/richard_dizeregas_blog/archive/2015/08/10/connecting-to-office-365-from-an-office-add-in.aspx

    Still with popups unfortunately :(

    Hope this helps


    • Edited by Benoit Patra Thursday, December 17, 2015 11:30 AM
    Thursday, December 17, 2015 11:30 AM