OAuth token emulation only ever generates one token per emulator session

Version

4.2.148513

Describe the bug

When relying on the emulator for OAuth token emulation, it will only ever generate a single token for the entire lifetime of the running emulator instance. You must shut down the emulator to get a new token.

All conversations also get the exact same token. So if I start multiple conversations they are effectively all given the same token value.

Restarting conversations also does not clear the token. This means that once I authenticate a single time, subsequent calls to GetUserToken will always return the token and so testing scenarios around OAuthPrompt (or even raw OAuth Cards) requires me to restart the entire emulator to go through the actual login process again.

To Reproduce

Steps to reproduce the behavior:

1. Launch a new instance of the emulator
2. Connect to a bot that uses an OAuthPrompt
3. Authenticate and notice that you are given the OAuth Card and have to click the button and trigger the token response event in the bot
4. Notice that you get a token such as "emulator_ABC123"
5. Start a new conversation tab -or- restart the original conversation
6. Attempt to authenticate again and notice that you are not prompted with an OAuth Card because the OAuthPrompt got a user token right away
7. Notice that the user token is the same as step 4, rather than a new token

Expected behavior

The behavior I would like to see is that the emulator store the token on a per conversation basis rather than as a single, global value. I believe this would solve both the scenario where I start multiple conversations or restart an existing conversation.

Additional context

This same problem existed in v3, so it’s not a regression.

NOTE: Being able to test this thoroughly requires that issue #1268 is fixed first, right now that is a blocker to this. One way to get around that right now, as is mentioned in that issue as a workaround, to disconnect from the network.

[bug]

[darrenj]

I’d like to suggest that we dont’ recycle this on a per-conversation basis, it’s totally reasonable to start a new conversation as the same User (same from.Id on the activity) and not expect authentication to be reset. Going down this route would mean a new conversation would require the user to log in each time. This would be a regression of current behaviour that customers/developers rely on and increase complexity.

Restarting the conversation with a new User Id (available through the restart conversation drop-down) however should aboslutely exhibit the proposed behaviour detailed above whereby a new conversation with a new UserId would prompt for authentication again and should not be cached. This caching is a real pain!

[carlosscastro]

This is resolved with the current code. If you start a conversation with the same user id, you don’t need to re-enter your credentials. If you start a conversation with a new user id, you need to re-enter your credentials.