Does Azure Bot Service support PKCE for OAuth connections?

Question

Does Azure Bot Service support PKCE for OAuth connections?

Kuldeep Ravaliya 0 Microsoft Employee

Does Bot Service support PKCE for OAuth connections? Both generic providers expose a PKCE Type field, but with it set to S256 we see no challenge emitted: "Generic Oauth 2" produces an authorize URL with no code_challenge at all, and the templated "Oauth 2 Generic Provider" sends code_challenge=%7BCodeChallenge%7D — the {CodeChallenge} placeholder passed through literally, while {ClientId} , {RedirectUrl} and {State} all substitute correctly.

Thanks!

User's image

Jose Benjamin Solis Nolasco 12,201 Reputation points Volunteer Moderator

2026-08-31T14:47:37.5+00:00

@Kuldeep Ravaliya I hope you are doing well,

Based on the current Microsoft documentation, Azure Bot Service supports generic OAuth 2.0 providers, but the documented Bot Service configuration does not show PKCE as a supported setting. The {CodeChallenge} placeholder therefore appears to be passed literally rather than dynamically generated.

So, for this scenario, I would not consider PKCE supported through the Bot Service generic OAuth connection configuration. If the identity provider requires PKCE, you would likely need to handle the OAuth flow outside the Bot Service connection.

Microsoft Learn – Identity providers in Bot Framework SDK
Ganesh Gurram 7,405 Reputation points Microsoft External Staff Moderator

2026-09-03T10:00:23.6533333+00:00

@Kuldeep Ravaliya - Following up to see if the below answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.

1 answer

Your answer

Jose Benjamin Solis Nolasco 12,201 Reputation points Volunteer Moderator

2026-08-31T14:47:37.5+00:00

@Kuldeep Ravaliya I hope you are doing well,

Based on the current Microsoft documentation, Azure Bot Service supports generic OAuth 2.0 providers, but the documented Bot Service configuration does not show PKCE as a supported setting. The {CodeChallenge} placeholder therefore appears to be passed literally rather than dynamically generated.

So, for this scenario, I would not consider PKCE supported through the Bot Service generic OAuth connection configuration. If the identity provider requires PKCE, you would likely need to handle the OAuth flow outside the Bot Service connection.

Microsoft Learn – Identity providers in Bot Framework SDK
Ganesh Gurram 7,405 Reputation points Microsoft External Staff Moderator

2026-09-03T10:00:23.6533333+00:00

@Kuldeep Ravaliya - Following up to see if the below answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 1

Hello @Kuldeep Ravaliya

Based on the current Bot Service documentation and the behavior you reproduced, don't treat PKCE as supported by Azure Bot Service OAuth connections at this time.

Microsoft documents the Generic OAuth providers and their supported templates. For the customizable OAuth 2 Generic Provider, documented placeholders include {ClientId}, {RedirectUrl}, {Scopes}, {State}, etc., but Microsoft does not document {CodeChallenge} / {CodeVerifier} as supported dynamic substitutions.

That aligns with your results:

Generic OAuth 2 with PKCE S256 doesn't emit code_challenge.
OAuth 2 Generic Provider sends {CodeChallenge} literally rather than generating/substituting a challenge.

The Bot Framework Token Service normally performs the OAuth authorization-code flow and manages the resulting tokens on behalf of the bot.

Therefore, if your identity provider requires PKCE, I don't see a documented way to implement it using the built-in Bot Service OAuth connection alone. You would likely need to implement the PKCE authorization flow outside the Bot Service Token Service, where your application generates and retains the code_verifier and supplies the corresponding code_challenge.

Given that the Azure portal exposes a PKCE Type field despite the documented/provider behavior, raise this with Microsoft Support. It could be an undocumented feature, a portal/backend mismatch, or a defect, and Microsoft would need to confirm which.

Avoid relying on the PKCE field in production until Microsoft confirms the expected behavior.

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.