AADSTS70007: 'query' is not a supported value of 'response_mode' when requesting a token

Question

So I created an application in Azure AD a few days ago. When requesting authorization code, I am getting the following error back when I ask for both code and id_token (in response_type parameter):

AADSTS70007: 'query' is not a supported value of 'response_mode' when requesting a token

Trace ID: xxxx-xxxx-xxxx-xxxx-xxxx

Correlation ID: xxxx-xxxx-xxxx-xxxx-xxxx

Timestamp: 2018-06-13 16:06:03Z

My request URL looks something like this:

https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=application-client-id&response_type=code+id_token&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=query&nonce=1528906255418&state=12345

However, I don't get any errors if I only ask for code and not id_token. So essentially, following URL works:

https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=application-client-id&response_type=code&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=query&nonce=1528906255418&state=12345

What is even more interesting is that if I use a client id of an application created a few months ago, the code works perfectly fine and Azure AD returns me both code and id_token.

I did find one similar problem here: https://sharepoint.stackexchange.com/questions/242669/aadsts70007-query-is-not-a-supported-value-of-response-mode-when-requesting but there was no answer provided for that question.

I'm curious to know:

• Why Azure AD does not throw any error for older application but for newer application? Has anything changed at the Azure AD level recently that will cause this problem? And that too for only newer applications.
• Is there a way to prevent this error from happening? I would very much like to use query as response_mode instead of form_post.

Condition

Answer 1

Two different authorization flows:

• If you want to use code + id_token in the response_type,you should be using OIDC Hybrid Flow.

• However, if you just use codein the response_type, you should be using Authorization Code flow.

So, These two kinds of requests are different OIDC Authentication flow due to their different response_types.

Meanwhile, two different response_modes:

• For form_post, form_post executes a POST containing the code to your redirect URI.When the Authorization Response is intended to be used only once, you should use form_post in reponse_mode. You can also see the details about form_post in this documentation.

• For query, In this mode, Authorization Response parameters are encoded in the query string added to the redirect_uri when redirecting back to the Client. For more details about query in response_mode, you can refer to this documentation.

So, you may be more clear about the different response_mode for different Authorization flows.

For Authorization code flow, you can use query or form_post, For Hybird flow, you can use form_post or fragment. For web applications, we recommend using response_mode=form_post, to ensure the most secure transfer of tokens to your application. (the Microsoft OpenId Connect middleware only supports hybrid + form_post)

Why Azure AD does not throw any error for older application but for newer application? Has anything changed at the Azure AD level recently that will cause this problem? And that too for only newer applications.

I'm not 100% sure, but AAD shouldn't change anything about its authorization/authentication level. Maybe you used different types of App or authentication flow.

Is there a way to prevent this error from happening? I would very much like to use query as response_mode instead of form_post.

Since the reason is caused by OIDC framework, I think you cannot use query for hybird flow request.You'd better use form_post in this flow if your app is a web app.

Additional, Azure portal is using this flow actually, but it may be a little different from what we can use. But you can see how the authentication/authorization works by catching its HTTP traffic via Fiddler. With this flow, you've to enable your App to allow implicit flow.

You can also see this sample for Authenticate using Azure AD and OpenID Connect Hybrid flow in this documentaion.

Osman

Many thanks @Wayne Yang for providing such detailed explanation! Let me read more about it and come back with any questions I may have. – Condition

Hi @GauravMantri , Please feel to let me know if you have any further questions about this case.;-) – Osman

You can also see this samplefor Authenticate using Azure AD and OpenID Connect Hybrid flow in this documentaion. – Osman

Answer 2

Adding an answer for the sake of completeness. Wayne's answer helped immensely!

So, instead of using response_type=query, I ended up using response_type=fragment and my new request URL now looks like the following:

https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=application-client-id&response_type=code+id_token&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=fragment&nonce=1528906255418&state=12345

And I was able to get both code and id_token back: urn:ietf:wg:oauth:2.0:oob#code=code&id_token=id_token&state=12345&session_state=c6989d04-48ff-40cd-86ac-0cd2670ee168

Removed urn:ietf:wg:oauth:2.0:oob# and then parsed the remaining string to get both code and id_token values in the application.

Condition

It's great! Cheers! – Osman