Bot token framework showing 6-digit magic code flow

Question

We're using a Bot Framework OAuth Connection with a Generic OAuth2 provider (LinkedIn). We generate the sign-in resource using UserTokenClient.getSignInResource() and launch it through the documented Teams msteams: { type: "signin" } mechanism. Authentication succeeds, but the Token Service is now consistently falling back to the 6-digit magic-code flow. What exact condition causes Token Service to choose magic-code verification instead of automatically completing the token exchange, and is there any supported way to force automatic token exchange?

Answer 1

Dear @Kuldeep Ravaliya

I understand you are looking to clarify why the Bot Framework Token Service defaults to the 6-digit magic code flow during LinkedIn OAuth authentication in Microsoft Teams, and whether automatic token exchange can be forced.

Question: Why Token Service Falls Back to the 6-Digit Magic Code

The 6-digit magic code is a fallback security mechanism used by the Bot Framework Token Service to prevent token hijacking. It occurs whenever the Token Service cannot securely verify that the user who completed the browser login is the same user active in the Teams chat session.

In your setup, this occurs due to three specific conditions:

• Provider Limitations (Generic OAuth2 vs. Entra ID): Automatic background token exchange (silent SSO via signin/tokenExchange) is natively supported only for Microsoft Entra ID (Azure AD v2). Third-party Generic OAuth2 providers (such as LinkedIn) require an explicit interactive login and consent dialog.
• Custom Sign-in Launch via getSignInResource(): Generating a raw URL via getSignInResource() and opening it through a generic link action bypasses the built-in Teams authentication callback. Because the popup window cannot communicate its success callback back to the Teams client context, the Token Service renders the 6-digit code as a security gate.
• Missing Popup Close Callback: If the OAuth completion redirect does not trigger microsoftTeams.authentication.notifySuccess(), Teams cannot capture the authorization state directly, forcing the manual code entry page.

Question: Can You Force Automatic Token Exchange?

• Silent SSO: No. You cannot perform silent, zero-click token exchange for 3rd-party OAuth2 providers like LinkedIn because the OAuth protocol requires external identity provider consent.
• Eliminating the 6-Digit Code: No. There is no supported way to force the automatic path when the identity/conversation correlation fails. Silent SSO is only fully supported for Microsoft Entra ID.

Please let me know if you need further assistance.

Answer 2

what do you mean by identities should match, do you mean to say the credentials should be the same?

Answer 3

The 6-digit magic-code flow is triggered when the identity that authenticates in the popup does not match the Teams conversation user. In that case, the Token Service can’t match the redirect state back to the pending OAuth session, so Teams falls back to magic-code verification.

This is expected behavior, not a bug.

Automatic completion happens only when the client can correlate the sign-in back to the same conversation and user context. If that correlation succeeds, Teams sends a signin/verifyState invoke and the SDK can exchange the code for a token without showing the user a magic code in the normal fallback flow.

There is no supported way in the provided documentation to force automatic token exchange when that identity correlation cannot be made. The supported approach is to ensure the authenticating identity matches the Teams session user. The documentation also notes that some channels can complete sign-in without the user noticing, but when the sign-in URL can’t be securely tied back to the same conversation/user, Bot Framework uses the 6-digit code as a security measure.

Also, if SSO token exchange succeeds with a TokenExchangeInvokeResponse status of 200, the client doesn’t show the OAuth card. For any other status, or if no TokenExchangeInvokeResponse is received, the client shows the OAuth card fallback.

Security note: the sign-in URL is tied to a specific conversation ID and user ID and should not be shared.

---

• SSO Troubleshooting
• User authentication
• About single sign-on