It does not say what to do or what the cause is if you get a 200 OK response with text/html instead of application/json.
It looks like it is trying to redirect or prompt for credentials which is odd in a client_id/client_secret case.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@nschuessler
Thanks for your feedback! We will investigate and update as appropriate.
@nschuessler
Would you be able to provide some more info on your issue - screenshots, step you're stuck on, etc. So I can gain a better understanding of your ask.
Is this a documentation update request to include the "what" when it comes to the 200 OK response? Or is this solely a troubleshooting type of question?
Thank you for your time
@JamesTran-MSFT Yeah, mostly a documentation request. I think the what in my case was either configuration setting wrong in the azure portal or using the wrong api to authenticate.
@nschuessler
Thank you for the quick response. Just to clarify, you want us to update the "troubleshooting" section for:
How to respond/handle a 200 OK response with text/html.
Solution:
Based off your case we can make the solution something along the lines of "confirm configuration settings in the azure portal and api used to authenticate"
Please let me know if this is correct? If not, can you clarify what you'd like updated/added in the documentation specifically. This way we can work with the author to get this updated.
Thank you again for you time!
@nschuessler is it possible you sent the request to /authorize instead of /token? I'm a bit leery of adding official troubleshooting help that's along the lines of "make sure you did the right thing instead of a wrong thing" since hopefully that's step number one in everyone's troubleshooting process.
We can add some common mixups as a section - e.g. "make sure you sent the request to /token", "make sure you used POST", "make sure you used urlencoding correctly" etc.
If I did it to /authorize instead of /token it would be because I called the wrong API on Microsoft.IdentityModel.Clients.ActiveDirectory API.
i.e. Using the wrong overload of AquireTokenXX for my scenario.
It may also be because I didn't have admin consent for my AAD application approved yet.
I have (mostly) solved the problem by not using any of the client APIs offered (Microsoft.IdentityModel.XX, and MSAL.Net) and going directly against the REST api. I now have roles in my access token but not any scp (scope) information so that's some progress at least. And it returns 401 or 403 for config problems rathern than 200 OK with text/html.
Basically, if you run into problems with these APIs you have to know the all the protocol details (to understand @hpsin question for example), be able to pull apart an access token and look at the fields, and all usage scenarios to figure out what API to call.
Hm, that sounds like an SDK bug then - it should be literally impossible to get back text/html using client credential SDKs. There's just no time when we would return that kind of error.
The only time we've seen issues like that on /token is when a firewall is in between an app and the internet injecting certain pages.
@nschuessler can you please provide repro steps with MSAL.NET on how you get in such a situation? this is really news for me
cc: @hpsin
I think there may be a misunderstanding here.
The 200 OK with text/html is coming when I add Authorization: Bearer <token> to the POST to the api I created with ASP .Net core that I want to access.
I was using HTTPClient so it may be following some redirects with the default settings or coming from deep inside the asp.net core middleware.
So even after getting a token, it is sending back text/html from my API with code for prompting for a password (although it is a lot of java script and very little HTML so I'm not 100% sure).
I don't have the repro anymore as it happened when trying to add auth to an existing AAD application entry being used by a live service (that didn't have admin consent). This caused a service outage so I had to revert it quickly.
But since the result was unexpected, and my outcome was not in the list of "Trouble Shooting" steps, I thought it would be helpful to add a section, thus the original comment.
@nschuessler - got it, thanks! That's super helpful. So you created an API and sent it the token, and your ASP.NET code sent back the HTML? @jmprieur - sounds like this is not related to token issuance and is more of a "how to build and call an API" question. Will let your expertise shine here :)
Hi @jmprieur, I believe Hirsch has passed this one over to you in https://github.com/MicrosoftDocs/azure-docs/issues/59693#issuecomment-665127738:
@jmprieur - sounds like this is not related to token issuance and is more of a "how to build and call an API" question. Will let your expertise shine here :)
@nschuessler Apologies on the delay in follow-up on this. Since we don't have a repro on this and it seems the cause is not entirely clear, it'll be difficult to provide break/fix explanation in a troubleshooting step. I move that we close this one out for now, and if you run into it again, we can verify and update then.
Closing issue as we need a repro to properly diagnose and assist. If you feel this was closed prematurely, however, do let us know. Thanks! #please-close
Most helpful comment
@nschuessler is it possible you sent the request to /authorize instead of /token? I'm a bit leery of adding official troubleshooting help that's along the lines of "make sure you did the right thing instead of a wrong thing" since hopefully that's step number one in everyone's troubleshooting process.
We can add some common mixups as a section - e.g. "make sure you sent the request to /token", "make sure you used POST", "make sure you used urlencoding correctly" etc.