Botbuilder-dotnet: OAuthInput does not work from within MS Teams chat context

[jsiegmund]

Version

4.10.0

Describe the bug

OauthInput for AdaptiveDialog is not working in MS Teams

To Reproduce

Steps to reproduce the behavior:

1. Implement OAuthInput dialog to connect to a Generic Oauth provider using bot service
2. Test locally, works
3. Test remote using webchat, works
4. Deploy in Teams using manifest
5. Card shows to sign in, clicking the sign-in button doesn't prompt any login / pop-up whatsoever, no message no nothing

Expected behavior

I'd expect the bot to behave the same as when using webchat, and thus display a prompt to login to the generic OAuth provider.

Additional context

Code snippet for the Oauth dialog creation, there's not much more to it:

_oauthDialog = new OAuthInput()
{
    ConnectionName = configuration["ConnectionName"],
    Title = "Sign in",
    Text = "Please sign in using OAuth",
    Property = "user.authToken"
};

Maybe this bug belongs to MS Teams instead, I'm not sure and I have no way of telling it does I guess.

[jwiley84]

Hi @jsiegmund Are you using a particular sample, or are you implementing this yourself?

[jsiegmund]

Hi @jwiley84, implementing it myself.

[mmiele]

@jsiegmund I have discussed this issue and the related Incorrect OAuthInput sample #1870 with the doc team. I am glad that you are making progress on your own and some of the info I provided was useful. Perhaps, we need to bring you into the discussion and use some of your findings in the documentation itself. If you agree, that is.

[jsiegmund]

Sure, I'd love to help out if I'm of any help.

[lauren-mills]

@jsiegmund - You may need to add token.botframework.com as a valid domain in your manifest in the Domains and Permissions tab

[jsiegmund]

Hi @lauren-mills, I tried this using the following steps:
1) Added the URL to the manifest
2) Increased the minor version number just to be sure (not sure if this is required to propagate changes?)
3) Re-added the bot in Teams.

Unfortunately, no difference.

[JonathanFingold]

The only other things I can think of to check:

1. Make sure all activities are forwarded to the adaptive dialog. Teams uses an invoke activity for sign in, instead of an event activity.
2. In my original proof of concept, I forgot to add the OAuthInput dialog to the adaptive dialog's internal dialog set. I don't know if that would break the Teams login flow. (I haven't tried this in a Teams bot.)

With respect to 2, my proof of concept looks like this now (with Dialogs.Add(MyOAuthInput); being the important addition):

    public class RootDialog : AdaptiveDialog
    {
        private OAuthInput MyOAuthInput { get; }

        public RootDialog(IConfiguration configuration) : base(nameof(RootDialog))
        {
            // Using the turn scope for this property, as the token is ephemeral.
            // If we need a copy of the token at any point, we should use this prompt to get the current token.
            // Only leave the prompt up for 1 minute. (Is there a way to not reprompt if this times-out?)
            MyOAuthInput = new OAuthInput
            {
                ConnectionName = configuration["ConnectionName"],
                Title = "Please log in",
                Text = "This will give you access!",
                InvalidPrompt = new ActivityTemplate("Login was not successful please try again."),
                Timeout = 1000 * 60,
                MaxTurnCount = 3,
                Property = "turn.oauth",
            };
            Dialogs.Add(MyOAuthInput);
        // ...

[jsiegmund]

I personally think that it's not an issue with handling a response or things not being directed to the dialog. Since the login card appears on screen as it should, that part should be fine. I'm going to further investigate what action is bound to the button on the adaptive card, cause it seems like Teams is for some reason blocking that action. That made sense in @lauren-mills reaction above; when the action points towards a URL which is not whitelisted in the Teams manifest this might be blocked because of that. That said I tried adding token.botframework.com which didn't work, but maybe the initial URL is something else?

Or perhaps there's some bug in rendering the card or the way that the card is being built that causes the button to misbehave.

The reason I think this is that the flow is working fine in other channels apart from Teams. So in my mind that rules out any issues in how the dialog is being constructed.

[jsiegmund]

Update: the URL returned from adapter.GetSignInResourceAsync indeed is token.botframework.com so that should have been fixed by adding it to the manifest.

[jeissing]

We have the same Issue. When comparing the versions 4.9 and 4.10 of the OAuthInput.cs you will notice
that in the method "ChannelSupportsOAuthCard" in version 4.10 the case statemant "case Channels.MSTeams" is no longer present. This leads to the fact that the Card is not generated as in 4.9, but is loaded from a resource. After we have reintroduced the mentioned case statemant, the MS-Teams login works again as expected. Probably something is wrong with the loaded card resource.

[jsiegmund]

Ok so that's this PR: https://github.com/microsoft/botbuilder-dotnet/commit/acdaec64488afc9e5c2889933abfaf2e9932f327#diff-8ba2f5749eeeffd205ecea167bd187b0. Pinging author @EricDahlvang on this issue.

The comment on the PR seems conflicting with the change: "* Teams DOES support OAuthCard." yet Teams was _removed_ from the ChannelSupportsOAuthCard method, indicating it doesn't support the card.

[jsiegmund]

Hereby verified that adding the line back in fixes the issue for me. Also doesn't break any of the tests. I took the liberty of creating an enormous PR for this fix ;). https://github.com/microsoft/botbuilder-dotnet/pull/4550

[EricDahlvang]

@jsiegmund #4550 pr would remove OAuthCard support for the teams channel.

[jsiegmund]

@EricDahlvang you're absolutely right and I was not paying attention it seems. That said. The PR does fix the issue, so 'the other way' is not working for Teams.

What I found next: line 377 sets the value of the card action back (value variable) to null for reasons I do not understand. There's a comment which states the SignInLink is only used when it's a speech channel, skill or an extra OAuthAppCredentials is passed in. That all does not apply to my Teams scenario so in return I get a button without a proper URL, which therefore does nothing. When I remove the else-clause, it works and no tests break but that kinda scares me since it was probably there for a reason.

[EricDahlvang]

@jsiegmund

Unfortunately, we have duplicate code in OAuthInput and OAuthPrompt, and it has diverged.

Those same lines in OAuthPrompt have been updated as follows:
https://github.com/microsoft/botbuilder-dotnet/blob/main/libraries/Microsoft.Bot.Builder.Dialogs/Prompts/OAuthPrompt.cs#L401

f (turnContext.Activity.IsFromStreamingConnection() ||
                    (turnContext.TurnState.Get<ClaimsIdentity>(BotAdapter.BotIdentityKey) is ClaimsIdentity botIdentity && SkillValidation.IsSkillClaim(botIdentity.Claims)) ||
                    _settings.OAuthAppCredentials != null)
                {
                    if (turnContext.Activity.ChannelId == Channels.Emulator)
                    {
                        cardActionType = ActionTypes.OpenUrl;
                    }
                }
                else if (!ChannelRequiresSignInLink(turnContext.Activity.ChannelId))
                {
                    value = null;
                }

This same code should be in OAuthInput. I've raised this issue: https://github.com/microsoft/botbuilder-dotnet/issues/4467 to track.

[tsuwandy]

@EricDahlvang, will this be addressed with R11 or before? Thanks!

[EricDahlvang]

@tsuwandy here is a PR to fix the issue: https://github.com/microsoft/botbuilder-dotnet/pull/4660 I tested this on teams before and after the fix (also, this is the same code in OAuthPrompt). I've created a separate issue to track de-duplicating this code: https://github.com/microsoft/botbuilder-dotnet/issues/4467

We can cherry-pick it to 4.10 once merged.