Documentation seems to mention that client's add-in code sends refresh token

[kasturgo]

Under Authorize the backend Web API below is what is mentioned
"Once the flow completes, the add-in sends the refresh token to the backend Web API and includes the SSO token (if available) or the Exchange identity token."

As far as I know if we use Implicit flow, we don't get refresh token and if we use Authorization code grant flow, we will not need to send refresh token to client and then send it back to client as the refresh token is already available on the webapi. Need some clarification around this.

---

Document Details

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

• ID: 53319dc9-a8e9-323e-6ccf-ce169b90abac
• Version Independent ID: 408dbc47-f781-b027-1596-2c91cbbde06b
• Content: Scenario - Implement single sign-on to your service - Office Add-ins
• Content Source: docs/outlook/implement-sso-in-outlook-add-in.md
• Product: outlook
• Technology: add-ins
• GitHub Login: @o365devx
• Microsoft Alias: o365devx

[AlexJerabek]

Thanks for reporting this @kasturgo.

@davidchesnut, I know you're working on this currently, but you could please provide clarification here.

[davidchesnut]

Hi @kasturgo,

Thanks! You are correct. I marked this as a doc bug and will make some updates to this article. As you point out you do not need to use implicit flow. The text is a bit confusing, but basically you need to call getAccessToken() to get the access token to your web server from Office SSO. When you call any APIs on your web server you pass this access token so that your web server can validate the signed in user (token validation.) Office caches the token so whenever you need it just call getAccessToken() again. If the server method requires Graph or other resources, it uses the On-Behalf-Of (OBO) flow to acquire a new token to that resource. The web server can cache any tokens using MSAL library caching so that subsequent requests will run efficiently.

Hope this helps!
David