Closed jker-org closed 1 year ago
Hi jkerst! Thank you for bringing this issue to our attention. We will investigate and if we require further information we will reach out in one business day. Please use this link to escalate if you don't get replies.
Best regards, Teams Platform
Thank you for reporting this issue, we will check this and get back to you.
@jkerst -When we mark our app as publisher verified then this blue badge is coming before publisher name. Could you please refer below doc for more details. https://learn.microsoft.com/en-us/azure/active-directory/develop/mark-app-as-publisher-verified
Also Refer the below document-https://learn.microsoft.com/en-us/azure/active-directory/develop/application-consent-experience
Hi @sayali-MSFT, thank you for the documentation! Unfortunately, the documentation won't help as our app is already verified. The problem is that the verified bade is not shown.
If you look at the second consent screen, you will see a verification badge and also the links to the privacy statement and terms is correctly shown. The second consent screen is shown when our app is asking for access token.
However, if you look at the first consent screen, you will see that for the same app, the verification badge is missing. Also the screen states that there are no privacy statements and terms. The first consent screen is shown when our app is asking for ID token / launch the app for the first time. Can you please check why the first consent screen for ID token is behaving so much differently than the second consent screen for access token?
Thanks!
@jkerst - Please reach out to the Identity org since they are the ones that render these consent dialogs. You can find guidance for reaching them here: https://identitydocs.azurewebsites.net/static/v2/get_help.html
Also found the related thread-https://learn.microsoft.com/en-us/answers/questions/724907/publisher-verification-status-missing-from-azure-s?orderby=newest Hope it is helpful!!
@sayali-MSFT : Thank you for the information. Unfortunately, we don't have access to both links. How can we get access?
@jkerst -Could you please share the error screenshot?
@sayali-MSFT :
For the first link, we are asked to login:
The second link works with incognito mode on. We will investigate the second link.
@jkerst Our Teams app had the same issue when we moved over to SSO tab login. What ultimately solved it was one of two things, though we're not clear on which.
1) We manually changed the "publisher domain" in the Azure app registration to match one listed in the teams app manifest file validDomains
field - previously it was set to a default tenant domain.
2) We made sure that the domain listed as the "publisher domain" was verified under the "Custom domain names" blade in the Azure portal.
@tomagendium: Thank you for sharing this! We will check that. We recently moved from azurefd.net to a custom domain and I was hoping that this will solve it. According to what you just said, we now try the following:
We add to validDomains in manifest: [app.domain.com, domain.com]. We also add both domains (subdomain & domain) to custom domain names on Azure. Before, we had a mix here. Maybe this solves it for us.
@jkerst Note that it's not so much about the domain the app is actually using in the tabs etc. but specifically the "publisher domain" value for the app registration, under the "branding and properties" section. I suspect it might have been the 2nd thing that solved it (making sure that it's added as a verified domain) but hopefully it solves it for you!
@tomagendium: Thank you, but so far we do not see any effect. Publisher Domain is identical to validURL is identical to custom domain names.
@sayali-MSFT : Any update on the "access denied" issue? I think now is a good time that someone from Identity org checks our case. We can not access this link: https://identitydocs.azurewebsites.net/static/v2/get_help.html
@jkerst And to confirm, the domain is marked as "verified" under custom domains?
@tomagendium : Yep, everything looks good here:
@tomagendium: Thank you, but so far we do not see any effect. Publisher Domain is identical to validURL is identical to custom domain names.
@sayali-MSFT : Any update on the "access denied" issue? I think now is a good time that someone from Identity org checks our case. We can not access this link: https://identitydocs.azurewebsites.net/static/v2/get_help.html
Sure, Could you please raised the issue here so that they may best help you.
FYI this is a known gap in the consent experience for which the Identity team does not currently have a timeline for a fix.
@AE-MS : Thank you very much! Do you know any workaround? We did notice that this does not happend to every app. Actually, for a lot of apps, the consent dialog for ID token is rendered fine.
I'm not super familiar with this area since I work in the teams-js side of things and not on the identity side of things, so I don't really have a ton of details, I just did some digging to see that there was an acknowledged issue when a Microsoft app like Teams is showing a consent dialog on behalf of a non-Microsoft app like in the scenario you describe.
Using the StackOverflow links above are the best way to interact with the Identity team to get more details, I believe.
Can you give me an example of an app in Teams where the consent dialog for the ID token doesn't have this issue? This might help the Identity team further locate the source of the gap. Thanks!
We have changed a lot of things in the last days. The consent popup for ID token is finally rendered correctly and shows the verification badge. We have no idea what the root cause was, but here is a list of things we have done in the last days:
Changing the endpoint from "bla.azurefd.net" to a verified subdomain of our domain (app.our-domain.com) in our manifest.
Created a new teams react example from teams toolkit 5.0.1. and combined this example with our app code.
Therefore, we have started fresh with a new package configuration: "@fluentui/react-components": "^9.18.0", "@microsoft/mgt-element": "^2.8.0", "@microsoft/mgt-react": "^2.8.0", "@microsoft/mgt-teamsfx-provider": "^2.8.0", "@microsoft/microsoft-graph-client": "^3.0.1", "@microsoft/teams-js": "^2.7.1", "@microsoft/teamsfx": "^2.2.0", "@microsoft/teamsfx-react": "^3.0.0", "axios": "^0.21.1", "react": "^18.2.0", "react-dom": "^18.2.0", "react-router-dom": "^6.8.0", "react-scripts": "^5.0.1", "@fluentui/react-northstar": "^0.64.0", "@fluentui/react-teams": "^6.0.0", "react-device-detect": "^2.2.3"
I hope this helps to anyone with the same problem. Issue can be closed.
Fixed, see comment above.
Hi jkerst! This issue is closed in our system. We would like your feedback on your experience with our support team and Platform.
Best regards, Teams Platform
We have developed an app for mutli tenants. We are using following libraries relevant for authentication:
We call the teams-js library to get the ID token like this (simpified):
As expected, the teams-js will show a consent popup dialog. Unfortunately, the popup dialog says that our app is not verified. Verification badge is missing. URL to privacy terms etc. is also missing.
Here is the dialog with some basic information. URL also looks fine. Please note that some information is marked due to security reasons.
Troubleshooting details Request Id: c78d2e62-c03e-4cbf-aad8-05508ff31a00 Correlation Id: d80e9460-69ec-4474-a080-51b7ac3fbcf4 Timestamp: 2023-06-15T07:17:47.140Z
Later on, we try to get an access token for graph api calls from teamsfx library. We get the token like this (simplified):
This actually works pretty well. As expected a consent popup dialog appears and this time all the information is correct. We have a verification badge etc. Also our privacy URL and terms are correctly linked.
Here is the dialog with some basic information. URL looks also fine. Please note that some information is marked due to security reasons.
Troubleshoot details
Request Id: 229eb678-2504-4347-a8e5-802e5ade1900 Correlation Id: 6cdb53d3-6d62-4130-9e82-8b1514842b1b Timestamp: 2023-06-15T07:20:24.334Z
Do you have any idea why this is happening? We checked AAD app configuration, but this also looks fine (second dialog is a proof to this).
Thank you for your help!