the Azure ACS offers an OAUTH endpoint – for access tokens. One gives the parameters of the authorization grant and it gives back an access token. Or rather it does if you know what to send, specifically.
To spy on a working user of the token endpoint (to learn the magical parameters that work), turn off https. Then install and use fiddler.
To make fiddler capture a server–initiated http request, we added the system proxy:
Since the endpoint is working over https, we had expected to be able to leverage the https MITM of fiddler. But, the client code is designed to detect MITM https (being a token endpoint consuming service, after all). Thus, it will not accept Fiddler’s spoofing certs ; they are always invalid.
But, we were luck enough to be able to send things over http (just so we could learn).
We can now see the name/value pairs sent, with which encoding, etc.
When we use our own code, we can now see the handshake with Azure ACS when depositing the authorization grant – and getting the authorization_code. So we know that the issuing criteria are satisfied (using a setup from some Microsoft sample code).
On the code consuming side, we see our request (which then we compare with the sample)
vs sample…(allowing for change of redirect value, when using our apparatus):