OpenID Connect Authorization Code Flow with Proof Key for Code Exchange (PKCE) not announced in metadata?

Azure AD supports PKCE on both the v1.0 and v2.0 endpoints.

v2.0 documentation: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow

v1.0 documentation: https://learn.microsoft.com/en-us/azure/active-directory/azuread-dev/v1-protocols-oauth-code

It should be:

"code_challenge_methods_supported": [
"plain",
"S256"
]

There may be issues using code flow if you are using B2C and PKCE with a browser app, however. https://github.com/manfredsteyer/angular-oauth2-oidc/issues/653

Also, you may need to change your redirect URI type to enable CORS. You can do this by going to the manifest editor for your app registration in the portal, finding the replyUrlsWithType section and changing the type of your redirect URI to SPA.

May I ask which guide you are following?

"code_challenge_methods_supported": [
"plain",
"S256"
] or "code_challenge_methods_supported": [
"S256"
], both would do but there seems no way to add it to the metadata document. Is there a way to configure it?

We want to use PKCE with custom apps as well as off-the-shelf apps. Some apps can be coded or forced to use PKCE but some rely on the metadata. Apps like kubelogin can't find "code_challenge_methods_supported" at our https://login.microsoftonline com/{tenantid}/v2.0/.well-known/openid-configuration so they fall back on Authorization Code Flow with client secret. We would like to get rid of client secrets.

Google, Okta, Auth0, they all announce "code_challenge_methods_supported" and work for us.

Do you have any update on this?
Neither Azure AD nor Azure AD B2C announce PKCE "code_challenge_methods_supported".

According to linked RFC in the original question - https://datatracker.ietf.org/doc/html/rfc8414 - when "code_challenge_methods_supported" is omitted, the authorization server does not support PKCE. However this is not the case for Azure AD/Azure AD B2C. They do not annouce "code_challenge_methods_supported" but support PKCE.

As @HD already pointed out, if there are any libraries which are deciding wheter to use PKCE or not relying on code_challenge_methods_supported, they might end up not using PKCE with Azure AD/Azure AD B2C.

It's been 6 months, and I'd like to +1 the question. AzureAD supports PKCE, but still fails to properly announce this fact in its openid-configuration document, therefore some client libraries fail when using AzureAD as IdP. Is there a reason why it is designed this way?

Is there an update on this? It's now the end of 2025 (4 years after the initial question) and this is still a problem.

One very concrete consequence of this decision not to include "code_challenge_methods_supported" in the openid-configuration document is that this runs afoul of the MCP specification (https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-code-protection). Meaning...we cannot reliably use Entra as an authorization server for MCP Servers.

I'm already butting up against this issue with tools like Cursor that flat-out refuse to work with Entra because PKCE support cannot be verified.