SSO flow for the `OnTeamsAppBasedLinkQueryAsync`

[wenytang-ms]

[Enter feedback here] Hi, while I reading Add code to enable SSO in your bot app, the second Note says that OnTeamsMessagingExtensionQueryAsync and OnTeamsAppBasedLinkQueryAsync from the TeamsMessagingExtensionsSearchAuthConfigBot.cs file are the only SSO handlers that are supported. Other SSO handlers aren't supported.. I found some mismatch in the doc.

First, there are some inconsistencies between dotnet sample and node.js sample. In dotnet sample, the OnTeamsMessagingExtensionQueryAsync returns a auth card but the node.js sample, the handleTeamsMessagingExtensionQuery returns a silentAuth card Why are the implementations of these two inconsistent?

Second, I tried the node.js sample, once running query without consent before, the silentAuth will trigger two composeExtension/query request and response, and the second request will take the sso token with 412 status, and show users the login button as following: but once switch to the link unfurling, the auth card just return one composeExtension/queryLink and show a auth card in the input box So I just replace the auth card with silentAuth card in handleTeamsAppBasedLinkQuery, and tried again, it seems that the silentAuth also trigger two composeExtension/queryLink with the seconde 412 request take the sso token, but show nothing to users.

Based on the above statement, can you provide some information about the design differences between auth and silentauth in message extension?

I'm the developer for TeamsFx, and we're going to find some solution to help users doing the consent native without any bot token store. It's seems silentAuth is a better solution to do the auth flow, so can you share about your consideration?

---

Document Details

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

• ID: 039ff5cc-7243-ce4b-527e-c152755eeb72
• Version Independent ID: 039ff5cc-7243-ce4b-527e-c152755eeb72
• Content: Code configuration for enabling SSO for bots - Teams
• Content Source: msteams-platform/bots/how-to/authentication/bot-sso-code.md
• Service: msteams
• GitHub Login: @surbhigupta
• Microsoft Alias: surbhigupta

[Nivedipa-MSFT]

@wenytang-ms - Thanks for reporting your issue. The design differences between auth and silentAuth in message extensions are as follows:

auth: When using auth, the message extension sends an authentication card to the user, prompting them to sign in. This card is displayed in the compose box, and the user needs to click on the card to initiate the authentication flow. Once the user signs in and grants consent, the message extension can retrieve an access token and perform actions on behalf of the user.

silentAuth: On the other hand, silentAuth is a more streamlined approach. With silentAuth, the message extension does not display an authentication card to the user. Instead, it silently initiates the authentication flow in the background. If the user has already granted consent, the message extension can retrieve an access token without any user interaction. If the user has not granted consent, the message extension can display a consent card to the user, but it does not interrupt the user's workflow.

The choice between auth and silentAuth depends on the specific requirements of your app and the user experience you want to provide. Here are some considerations:

User Experience: Auth provides a more explicit and visible authentication flow, as it requires the user to click on the authentication card. This can be useful if you want to educate the user about the actions that will be performed on their behalf. SilentAuth, on the other hand, provides a more seamless experience as it does not interrupt the user's workflow.

Consent: With auth, the user is explicitly prompted to grant consent during the authentication flow. This can be useful if your app requires specific permissions that the user needs to be aware of. With silentAuth, the consent flow can be handled automatically in the background, without any user interaction. This can be useful if you want to minimize the number of consent prompts for the user.

Token Storage: With auth, the message extension needs to store the access token securely, as it needs to be used for subsequent API calls. This requires additional considerations for token storage and security. With silentAuth, the access token is retrieved on-demand and does not need to be stored by the message extension.

In the case of the sample code you mentioned, the implementation differences between the .NET and Node.js samples are likely due to the different programming languages and frameworks used. The specific implementation details may vary, but the overall concept of auth and silentAuth remains the same.

If you are looking for a solution to help users perform consent natively without any bot token store, silentAuth can be a good option. It provides a seamless authentication experience for the user and eliminates the need for token storage. However, it's important to consider the specific requirements and user experience of your app before making a decision.

Please let us know if you have any further query here?

[wenytang-ms]

@Nivedipa-MSFT thank you for your response. maybe the dotnet and node.js has different framework or others. so let's just take node.js sample, I tried the silentAuth and auth consent flow in Message Extension query as following this is auth consent flow this is silentAuth consent flow and I also tried silentAuth and auth in message extension link unfurling, the link unfurling only support auth, silentAuth is invalid. is there any intuition for such two functions? Or teams support silentAuth for query but link unfurling not. Can developers only confirm these features through debugging?

[wenytang-ms]

there is still another inconsistent code snippet provided as node.js in this doc At the head of this doc to create the CloudAdapter

    // Create adapter.
    // See https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-basics?view=azure-bot-service-4.0 to learn more about how bots work.
    const adapter = new CloudAdapter(botFrameworkAuthentication);

but at the end of this doc add token to token store, there use adapter to exchangeToken token

async tokenIsExchangeable(context) {
    let tokenExchangeResponse = null;
    try {
        const valueObj = context.activity.value;
        const tokenExchangeRequest = valueObj.authentication;
        tokenExchangeResponse = await context.adapter.exchangeToken(context,
        ......

as far as I know, the cloudAdapter does not have any implemetation like exchangeToken, so the code sample make me really confusion.

[Nivedipa-MSFT]

@wenytang-ms -

1. Yes, you are correct. For the zero install link unfurling feature in Teams, the bot can only send back a response as result or auth as the value for the type property in response to the composeExtensions/anonymousQueryLink invoke request.

   The reason for this is due to the nature of the zero install link unfurling feature. This feature is designed to provide a preview of the content of a link before a user has installed or authenticated your app. Therefore, it needs to be able to handle situations where the user is not authenticated.

   In the case of auth, the bot sends back a response that prompts the user to authenticate. This is useful for scenarios where the content of the link requires user authentication to view.

   On the other hand, silentAuth is a response type that is used when the bot attempts to authenticate the user silently, without prompting the user for credentials. This is typically used in scenarios where the bot has previously authenticated the user and has stored the user's credentials. However, in the context of zero install link unfurling, this is not applicable as the user has not yet installed or authenticated the app.

   Therefore, while silentAuth is supported for other types of bot interactions in Teams, it is not supported for zero install link unfurling.

2. CloudAdapter class does not have a method called exchangeToken. However, the CloudAdapter class does inherit from the BotAdapter class, which does have a method called exchangeToken.

Please let us know if you have any further query here?

[wenytang-ms]

@Nivedipa-MSFT For the 2 response. Neither BotAdapter or CloudAdapterBase has any method called exchangeToken, please help verify this, thanks!

[ChetanSharma-msft]

Hello @wenytang-ms - We are looking into this issue and let you know the updates.

[Prasad-MSFT]

@wenytang-ms - Yes, the BotAdapter class in the Microsoft Bot Framework has a method called exchangeToken that can be used to exchange a token for a different token. This method is part of the BotFrameworkAdapter class, which extends the BotAdapter class. https://learn.microsoft.com/en-us/python/api/botbuilder-core/botbuilder.core.botframeworkadapter?view=botbuilder-py-latest#methods

[wenytang-ms]

according to this comment, the BotFrameworkAdapter already deprecated and use cloudAdapter instead, so please verify such method on cloudAdapter class.

[Nivedipa-MSFT]

@wenytang-ms - We are closing the issue as the PR with the necessary changes has already been completed for this. Change type [auth] to [silentAuth] and Converting [BotFrameworkAdapter] to [CloudAdapter] - msgext-search-sso-config sample by Harikrishnan-MSFT · Pull Request #968 · OfficeDev/Microsoft-Teams-Samples (github.com)

[microsoft-github-policy-service[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 3 days. It will be closed if no further activity occurs within 3 days of this comment.