Closed JMS-1 closed 6 years ago
I checked https://tools.ietf.org/html/rfc6749#section-2.3.1 and it seems that using client_id and client_secret in the BODY is an acceptable alternative. Is it possible to extend your client to support it?
Jochen
Just set the appropriate token_endpoint_auth_method
as part of your client metadata.
I try to use the client against some commercial server (https://www.cidaas.com/) with the code flow. Anything works fine but when I try to resolve the code to some access token using authorizationCallback() this fails (unauthorized client) - I'm quite sure that in principal the call is ok at least it works against the oidc-provider with as is.
Apparently (?? this is my current analysis ??) the server ignores the Basic Authorization Header with the id/secret and expects these to be present in the body sent using the grant() method - in JSON fields client_id and client_secret (see Postman https://www.getpostman.com/collections/fc8276e42c38fc0ba74f).
Is there any way to configure (or intercept) your client so that the grant() POST body includes the client data as well? If not: is this behaviour so uncommon that I should ask the provider to better conform to standards - what IS the standard for an authentication_code grant? If both comes out to be a big NO I will do the HTTP request by myself but I really would like to avoid that.
Thanks for any advise!
Jochen