BAD REQUEST on Posting to token endpoint with dotnet

I am using dotnet for the process, but I am staring at this code and have quadruple checked all the values, I am failing to see what I missed? I thought perhaps I had a typo on one of the params but I checked that many times.

Am I missing something important here?

Note: when debugging I can definitely see that code, client_id, client_secret, and redirect_uri are all getting set with the values I expect.

After investigating I realized I can pull from the Content still to get more information, the error is a mismatched redirect uri.

The thing is, I have checked this and I dont see what would cause that.

and in My Clients:


As far as I can tell, that is correct, and the weird thing is the fact we got to the Token stage (and have the code) means my first redirect url is working perfectly fine for the first step of the oauth process… so what gives?

Another update… using the same redirect url for the Authorization Callback works.

I think maybe for some reason the second url in My Clients in the Redirect URIs field just… isn’t working?

I separated it with a space and it just straight up isnt working, but if I use the first url instead its fine. So I guess… that works? I am curious why its like that though…

Protocol (https / http) difference in URLs can cause that. You should check where the user starts the auth process from. If the user starts from a http:// url and your redirect url is https://, it will fail.

In my screen shot in my second post, the debug shows that it is https, and the Redirect URIs entry in “My Clients” is also https.

Then you must check and confirm the redirect url in your login/flow link and the one in your app are the same in all instances of the code. There may be some point in which it may be filtered or overridden.

The spot in my app, in the screenshot in my second post, is the only place it exists.

I also linked the code directly in my first post in this topic, as you can see on it, the URL is defined and basically immediately consumed a couple lines later.

There isn’t really any room for issues to occur with regards to it. My pic in my second post is paused in the debugger with the actual runtime value of the redirect uri being shown, and literally 4? 5? lines of code later, it gets consumed.

I also can pause the debugger on the response to see what the original request was and the redirect Uri is definitely correct.

I straight up used the debugger at runtime and copy pasted the URI 1:1 from the debugger to the field on My Clients.

I don’t see in my pic there any discrepancy between the two URIs.

Is all of this happening within the same protocol? Ie, you start from SSL or non-SSL page, you go to and back, and where you land is the same protocol? There has to be some place where things go amiss. It may not be evident from the code. You may need to log the state of that url in every step.

Also server side redirects that may be directing the flow from http:// to https:// and vice versa may be suspects.