This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(185.6, 78%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJR%3C/text%3E%3C/svg%3E)
We have an application that uses Azure Active Directory to authenticate our users. We have been using the Azure AD OpenID Connect metadata document v2 endpoint with the client_id query param (ex., https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration?client_id={client_id}) for months now. Suddenly, last week, GET calls to that URL started failing because that endpoint expects a jwks_extensions parameter when using the client_id query param. I cannot find any documentation or change notice about this or any documentation on the jwks_extensions parameter.
Using the appid query param instead of client_id seems to provide the same functionality that client_id use to but again, I can find no documentation of this change. Nothing listed in these breaking changes seems to be related. I have not been able to find references elsewhere. https://learn.microsoft.com/en-us/azure/active-directory/develop/reference-breaking-changes
{tenant} is a placeholder for our Azure tenant ID. {client_id} is a placeholder for the Application/Client ID of application registered in Azure.
Original v2 URL: https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration?client_id={client_id}
New v2 URL: https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration?appid={client_id}
Microsoft does not maintain documentation about their APIs and can change them at will with no prior notice. Proceed with caution.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(246.4, 20%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESM%3C/text%3E%3C/svg%3E)
Hi @Jonathan Rigsby ,
Thanks for reaching out.
I'm sorry to hear that you are facing issues with the OpenId connect metadata endpoint https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration?client_id={client_id})
AFAIK, client_id is not officially documented anywhere to use to query metadata endpoint. Could you please confirm why you are using client_id query param at first place.
We can still query metadata endpoint with clientid, appid or app_id , but officially we only support appid as mentioned https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#validate-the-signature
As other query param are not officially supported or documented, that can be obsolete at any time without notice.
Hope this answered your query.
Thanks,
Shweta
Please remember to "Accept Answer" if answer helped you.
I am researching why the client_id param was used initially. Where is the official documentation for this API? The article you linked is a how-to guide not API documentation. It doesn't say anything about officially supporting one param or another, it just mentions appid.
Only items with documentation are considered officially supported. Within our documentation, we solely reference "appid," which remains consistently supported. Any alterations to the appid will also be duly updated in the documentation.
Please remember to "Accept Answer" if answer helped you to help other community members as well.
This is really unacceptable. How can my company have confidence in using Azure products if the APIs can change without warning and break our applications?
Again, what documentation?
""appid," which remains consistently supported" Does that mean there will actually be a public notice about the change PRIOR to the change?
I empathize with your frustration.
My suggestion would be to stick to using only the features that are officially documented by us. According to our documentation, "appid" is supported, and in case of any changes, we will make sure to update and notify in advance.
Thanks,
Shweta
Please remember to "Accept Answer" if answer helped you.
I wanted to check in and see if you had any other questions or if you were able to resolve this issue?
If you have any other questions, please let me know. Thank you for your time and patience throughout this issue.
If the information helped address your question, please Accept the answer. This will help us and also improve searchability for others in the community who might be researching similar information.
If you can provide an answer as to why the functionality has been changed, that would be helpful.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(44.800000000000004, 39%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGG%3C/text%3E%3C/svg%3E)
Hello Support Team,
I am encountering the same issue with my Azure app services authentication integration. When attempting to authenticate users through my Azure App Service, I receive the following error:
"error": "invalid_request", "error_description": "AADSTS1004008: Required parameter 'jwks_extensions' has not been provided
I have reviewed the OpenID Connect discovery document for my Azure AD tenant, and I do not see any mention of a jwks_extensions parameter. The relevant metadata is for the Token Endpoint, JWKS URI and Authorization Endpoint.**
**
It appears that jwks_extensions is not part of the standard OpenID Connect configuration and is not included in the metadata document. I am unsure why this parameter is being required or where it should be provided.
your support and recommendations would be greatly appreciated.