search

OfficeDev / office-js-docs-pr

Microsoft Office Add-ins Documentation
https://learn.microsoft.com/office/dev/add-ins
Creative Commons Attribution 4.0 International
400 stars 247 forks source link

Can tokens to custom back-end services be returned to Office Add-in client-side code? #4288

Closed LapNik closed 9 months ago

LapNik commented 9 months ago

There is a note on this page saying to always perform the On-Behalf-Of flow on the server-side and that the token should not be returned to client-side code. Why is that? Is there a technical reason why Office Add-ins are more likely to leak client-side variables or should Graph API specifically never be used from single-page applications because a browser context cannot be trusted?

Does this recommendation (or requirement?) also apply for non-Microsoft APIs that I control? If I want to authorize requests to my own back-end services, which would normally be used through single-page applications, can I then return the tokens to the add-in client-side code to use the APIs directly or do I need to implement an API proxy?

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

AlexJerabek commented 9 months ago

Thanks for the question @LapNik.

@davidchesnut, could you please provide some context?

LapNik commented 9 months ago

Getting the access token to the client-side code would be a huge help because the back-end services might be in an on-prem private network and inaccessible to the add-in server-side code.

davidchesnut commented 9 months ago

Hi @LapNik,

It's mostly about good security practices. web browsers in general are not a safe place to store anything secretive. Also the token issued by the OBO flow will have the audience set to your middle-tier (not the client). Which implies you shouldn't be sharing it anywhere outside the middle-tier.

It's important to note this is not specific to Office Add-ins. The Microsoft identity documentation provides a good warning note about the pitfalls of sharing an OBO token at https://learn.microsoft.com/entra/identity-platform/v2-oauth2-on-behalf-of-flow#middle-tier-access-token-request.

In terms of other APIs and tokens it will depend on what you want to achieve. For example, if you want to use SPA with auth code flow you'd want to follow documentation such as the Tutorial: Sign in users and call the Microsoft Graph API from a JavaScript single-page app (SPA) using auth code flow. Note that the MSAL.js package provides caching mechanisms to help protect the token. And this token would have different audience settings and other claims as part of auth code flow.

Hope this helps, David

LapNik commented 9 months ago

Thanks @davidchesnut, the OBO token sharing pitfalls clear this up a lot. I think the main reason why we would want to avoid sharing the token is Conditional Access and device-based policies. As a correction, I think the access token received through OBO would have the back-end service as the audience instead of the middle-tier, but that does not affect the above concerns.

It's unfortunate that we can't use Office Add-In SSO feature for single-page add-ins, at least without masking the Conditional Access signals of the login. I'll see if we can manage with the auth code flow.