Closed richard-peters closed 8 months ago
Experiencing the same issue resulting in the unavailability of an add-in thus a major problem for our business!
Despite SSO being available since 2017, recent MS articles emphasise this as in preview only (not to be used in production) - this is confusing given the functionality seems to exist in release 1* of office.js
We're refactoring to use the Dialog UI / Authorization Code Flow, with a OBO exchange server side to get around it.
Hi, Same issue here, any clue?
We see the same issue on multiple tenants. We have a fallback for when SSO doesn't work, but since 13005 is a valid error (no consent) we aren't overwriting this.
We were wondering if perhaps it's related to the changes made for SPFx 1.10? Since that now offers a beta for SPFx in Outlook online and uses some kind of easy authentication flow. https://docs.microsoft.com/en-us/sharepoint/dev/spfx/office-addins-create:
There are following benefits on using SharePoint Framework as the platform for your Outlook Web App add-ins: [...]
- Simplified authentication to access different services in Microsoft 365
- You can benefit from the same permission and access management model as within SharePoint with easy access to Microsoft Graph APIs and other services
https://github.com/SharePoint/sp-dev-docs/wiki/SharePoint-Framework-v1.10-release-notes
Hi Same issue?
@richard-peters what is the build number of your Outlook client? The preview API has been updated and provides additional parameters documented here: https://docs.microsoft.com/en-us/javascript/api/office-runtime/officeruntime.authoptions?view=excel-js-preview. This particular error looks like Office needs to prompt the user for consent, but it is a silent API by default. You could try passing in allowConsentPrompt: true to see if it resolves the issue. If you are using centralized deployment and granting consent via an admin to users in the organization, this should be unnecessary if the application/manifest are configured properly. Make sure you have granted consent for openid and profile scope, and preauthorized the Office client id to your application (d3590ed6-52b3-4102-aeff-aad2292ab01c). The steps can be found here: https://docs.microsoft.com/en-us/office/dev/add-ins/develop/register-sso-add-in-aad-v2
I'm not Richard but I can add some info from our tenants :)
We see that the same add-in works fine when in Outlook Desktop, but it will give the consent issue when used in Outlook Online (same user). The admin had given correct consent across all users in the tenant before, and we've tried redoing this but it makes no difference. Is this new property you mention needed if an admin has given consent on behalf of their users?
Our issue is also related to Outlook Online when calling:
Office.context.auth.getAccessTokenAsync((result) => { .. });
from office-js, which has no parameters.
I can confirm to have granted admin consent for openid, profile and preauthorized the office client (d3590ed6-52b3-4102-aeff-aad2292ab01c).
I read that OfficeRuntime is only available to the hosts: Excel, PowerPoint, Word (not mentioning Outlook)
Using OfficeRuntime.auth.getAccessToken instead of Office.context.auth.getAccessTokenAsync solves the issue for Web Outlook (office.com and office365.com domains). The documentation says it doesn't work for outlook.com. Judging from the documentation, the SSO functionality moved to OfficeRuntime around November 6th https://github.com/OfficeDev/office-js-docs-pr/commit/e346a42d492c1471beb23c662f5d6bf7d50a5166
Using OfficeRuntime.auth.getAccessToken instead of Office.context.auth.getAccessTokenAsync solves the issue for Web Outlook (office.com and office365.com domains). The documentation says it doesn't work for outlook.com. Judging from the documentation, the SSO functionality moved to OfficeRuntime around November 6th OfficeDev/office-js-docs-pr@e346a42
For me somehow it only works when providing both - allowConsentPrompt, allowSignInPrompt - options, set to true:
OfficeRuntime.auth.getAccessToken({ allowConsentPrompt: true, allowSignInPrompt: true })
Only this way it silently resolves the token. Seems like a bug to me =\
OfficeRuntime.auth.getAccessToken({ allowConsentPrompt: true, allowSignInPrompt: true }) solves it for me also.
For your information: Before that, I tried the Authorization Code Flow according to https://docs.microsoft.com/de-de/azure/active-directory/develop/v2-oauth2-auth-code-flow as suggested by @richard-peters
First step of calling /oauth2/v2.0/authorize
worked, second step of calling /oauth2/v2.0/token
however resulted in
"AADSTS65001: The user or administrator has not consented to use the application with ID 'xxx' named 'yyy'. Send an interactive authorization request for this user and resource.
@christianecker - We implemented the auth code flow in conjunction with Dialog.UI (to support desktop), which returned the auth code, which was exchanged server side for access tokens (and renewal) - as this was an interactive authorisation request, we didn't get the same exception.
SSO is still in preview, so we weren't comfortable deploying to production.
Hi all, I've assigned this to our team to investigate. I'm sure you've already checked the Troubleshooting error messages in SSO topic. It might also be a good idea to reach out to the developer community on Stack Overflow (use [office-js] and [outlook-web-addins] tags).
@sash1350git could you let me know what host you are having this issue? Is this Outlook win32/mac/web? Regarding Office.context.auth.getAccessTokenAsync and OfficeRuntime.auth.getAccessToken they should both be supported. If it only works passing allowConsentPrompt: true, allowSignInPrompt: true and not empty params, but no prompt shows, this sounds like a bug.
@dsaunders45459 - I was experiencing the issue on Outlook mac & web (Office 365) - monthly build.
@dsaunders45459 - web version, and yes, that's correct:
it only works passing allowConsentPrompt: true, allowSignInPrompt: true and not empty params, but no prompt shows
OfficeRuntime.auth.getAccessToken({ allowConsentPrompt: true, allowSignInPrompt: true }) solves it for me also.
Closing this issue as SSO is working in all platforms now. Please reopen this issue if you still face this issue.
As of yesterday we're unable to receive a SSO token from the getAccessTokenAsync request.
error: OSF.DDA.Error name: "Preauthorization missing." message: "Missing grant for this add-in." code: 13005
The application was working previously and there have been no application / manifest changes.
I have reauthorised the application (on-behlaf-of flow) as the tenant administrator and the issue persists.
We are only experiencing this issue on Outlook (desktop and online across PC & MAC). Word is still working (which uses the same core authentication code).
SSL certificates are valid.
Have there been any breaking changes?