Microsoft identity platform and OAuth 2.0 authorization code flow error 400 Bad Request

Question

I need a bit of help understanding which is the problem with Microsoft Identity Platform login on my cms (ASP.NET Webforms). It used to work without problems, last time I tried was maybe a month ago.

Now I'm receiving a "400 bad request" response on the second step of the code flow authentication, when I send back the authorization_code that I received after the user login to the token endpoint, to request the access_token.

The original GET request to send the user to the Microsoft login panel is (I split it for readibility):

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
?client_id=myclientappid-xxxx-xxxx-xxxx-xxxxxxxxxxxx
&response_type=code
&redirect_uri=https%3a%2f%2feva3.com%2flogin
&scope=openid
&state=mycustomencodedappinfos
&response_mode=query

It works and microsoft redirects the user to the callback url specified in app registration and in the request (local developement machine).

Then my POST request to receive the access_token, when I receive the error response, but used to work up to at least 1 month ago, is this:

https://login.microsoftonline.com/common/oauth2/v2.0/token
code=M.R2_BAY.21818906-b374-00e0-xxxxx-xxxxxxxxxxxx
&scope=openid
&client_id=myclientappid-xxxx-xxxx-xxxx-xxxxxxxxxxxx
&client_secret=myclientSecretxxxxxxxxxxxx
&redirect_uri=https://eva3.com/login
&grant_type=authorization_code

Parameters are encoded and sent that way:

I double checked the parameters with the official docs. I'm passing them as a POST request (application/x-www-form-urlencoded) with:

Using response As System.Net.HttpWebResponse = CType(request.GetResponse(), System.Net.HttpWebResponse)
If response.StatusCode = System.Net.HttpStatusCode.OK Then
    Using reader As StreamReader = New StreamReader(response.GetResponseStream())
        Return reader.ReadToEnd()
    End Using
End If
End Using

Any hint on why this that used to work now gives back bad request? I tryed to check docs for changes but nothing changed apart:

Starting in November 2020, end-users will no longer be able to grant consent to most newly registered multi-tenant apps without verified publishers. This will apply to apps that are registered after November 8th 2020, use OAuth2.0 to request permissions beyond basic sign-in and read user profile, and request consent from users in different tenants than the one the app is registered in. A warning will be displayed on the consent screen informing users that these apps are risky and are from unverified publishers.

But my app has been registered before that date, also I'm just asking for the openID (I just need Microsoft id for that user that I have linked in my local db), also I can actaully loginn and receive back the autrhorization code in the first step of the flow.

Any help is greatly appreciated. Thank you so much

EDIT: I tested the second request in postman too and I receive this error, but the grant_type param is there of course:

{
"error": "invalid_request",
"error_description": "AADSTS900144: The request body must contain the following parameter: 'grant_type'.\r\nTrace ID: 6a487d0d-3d7f-4d8b-896f-7df8453ebd00\r\nCorrelation ID: 16efbdc3-4c3d-4e0d-8835-b086b77890fb\r\nTimestamp: 2021-01-02 18:51:43Z",
"error_codes": [
    900144
],
"timestamp": "2021-01-02 18:51:43Z",
"trace_id": "6a487d0d-3d7f-4d8b-896f-7df8453ebd00",
"correlation_id": "16efbdc3-4c3d-4e0d-8835-b086b77890fb",
"error_uri": "https://login.microsoftonline.com/error?code=900144"

}

In post man you can send the parameters both as form-data or x-www-form-urlencoded. I tried both with no luck. Funny thing same happens using the microsoft "demo" links in the doc. They provide the direct link to postman, you just have to change the code that you receiver from the first link, but I get the same identical error complaining no grant_type param is specified in the post.

Gelya

Answer 1

Ok I found the issue. I will leave all my process in the question in case any other use will have a similar issue.

The first problem was the library used to make the request:

 System.Net.HttpWebResponse

This "very smart" library,has the nice habit of throwing an exception when it doesn't receiver a 200 status code back... What put me on the right track was this post: .Net HttpWebRequest.GetResponse() raises exception when http status code 400 (bad request) is returned

Thanks to that user on Stack Overflow I've been able to read the real response error which was that in my redirect url I forgot to add a trailing / at the end. So I added a second URL in the Azure portal as a callback url. Now I have both /login and /login/ as callback destination urls. Since in my app I retrieve this url dynamically, maybe I changed some function in the meanwhile that sent back the url without / at the end... that's why it was not working as before.

Gelya