Azure AD authentication with seamless sign on: undefined tenant passed to AAD endpoint
Category
- [ ] Question
- [ ] Typo
- [x] Bug
- [ ] Additional article idea
Expected or Desired Behavior
When a webpart authenticates with a backend Api secured by Azure AD, a token is obtained and used by the AadClient of SPFx. Even if the tenant is using seamless signon where the token request passes the https://autologon.microsoftazuread-sso.com/ endpoint.
Observed Behavior
In some cases, the tenant parameter needed by https://autologon.microsoftazuread-sso.com is passed as 'undefined'. Example: https://autologon.microsoftazuread-sso.com/undefined/winauth/ssoprobe?client-request-id=719482f2-1966-4d1e-8040-0562db4e975e&_=1570098222065
This causes the following HTTP 400 error: AADSTS90002: Tenant 'undefined' not found. This may happen if there are no active subscriptions for the tenant. Check with your subscription administrator.
This causes no token to be produced, causing a timeout in the SPFx middleware after 3 retries (which all result in the HTTP 400 error above).
The following error is produced in the browser console afterwards:
'Token Renewal Operation failed due to timeout'
Steps to Reproduce
The issue cannot be reproduced reliably. It only seems to popup with users having a Seamless SignOn enabled tenant.
- You need to have a tenant with Seamless SignOn enabled
- Create a webpart that fetches a token for a backend Api
- Place the webpart on a sharepoint page and navigate to it
- The authentication fails, producing errors in the browser console
Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.
Any update @andrewconnell? We are hitting this issue as well...
/cc: @macewindu1
@hajekj Sorry, I can't provide an update as I don't work for Microsoft & thus can't speak on their behalf for issues/errors.
I just helped label the issue.
I am also facing this issue, is it still being reviewed?
Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.
If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.
We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.