ADFS 2019 - client-request-id query string parameter on authorize request (oauth2) RRS feed

  • Question

  • Hi,

    We're using ADFS 2019 with a WAP configured in passtrought.

    We're running into an issue with a query string parameter, client-request-id, that is added on the authorize request response for Oauth2.

    When not going through the WAP, the additonnal string parameter is not there.  However, as soon as the authorize request goes through the WAP, we get the additionnal parameter after the authorization code. 

    The problem we have is that we believe the client app (outside of our control) sees this additionnal parameter as part of the authorization code and then calls the token endpoint with a then invalid code, resulting in a bad request - 400 (this is a bit of a wild guess...).

    In the ADFS properties, we saw that we can set that additionnal parameter (used for tracing in a server farm) using  [-SendClientRequestIdAsQueryStringParameter <Boolean>]. Is is set to false for our ADFS instance.  I also found in a Microsoft PDF about ADFSOAL protocol that this query string parameter is added by the client server in a server farm scenario. However, we can't find anything about how to turn it off for the WAP.

    Anyone have an idea?

    Thank you,


    • Edited by Sim_D Thursday, May 30, 2019 2:17 PM
    Thursday, May 30, 2019 1:27 PM

All replies

  • Did you manage to resolve this issue?

    I'm experiencing the same issue where the addition of client-request-id causes the redirect back to the application to fail.  ADFS authenticates correctly.

    From a test client, after the failure I can enter the application URL minus the client-request-id and it logs me into the application ok.


    • Edited by m00se73 Monday, February 17, 2020 12:30 PM
    Monday, February 17, 2020 12:02 PM
  • Hi,

    We haven't found a way to rid the request from this extra parameter, but our understanding is that the client id shouldn't be an issue for the caller and our token endpoint. In our case, we contacted the client (service provider) about it and they eventually confirmed the issue was on their side, it had something to do with the library they were using to call our Oauth endpoint (Unfortunately, i am not sure what it actually was though).

    Monday, February 17, 2020 1:41 PM
  • Hi,

    Thanks for the quick response!

    For reference, if anyone else stumbles across this page, the app we're working with is Dynamics 2016.  If I find a solution, I'll post it here.

    Monday, February 17, 2020 1:55 PM