I've seen many customers have a security review that comes back flagging the use of GET on the API and putting client id and secret on the URL. Apparently people are somehow convinced that that's "in public".
I've explained to people that it doesn't put it in cleartext to the public exactly (which is what people seem to think), as all connections are HTTPS. There is an abstract risk related to logging or something like proxy intercepting - if they log full URLs somewhere then that would be logged in a file somewhere and then that file and who can see it is important.
Regardless, it's not how OAuth 2.0 is supposed to work and there is risk associated with GET, which is why it's not allowed in the OAuth 2.0 spec. Would it be possible to update these pages to show that you can use a POST? i.e. both of these work perfectly well:
curl --location --request GET 'https://123-ABC-456.mktorest.com/identity/oauth/token?grant_type=client_credentials&client_id=<client id>&client_secret=<client secret>'
curl --location --request POST 'https://123-ABC-456.mktorest.com/identity/oauth/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=<client id>' \
--data-urlencode 'client_secret=<client secret>' I'm not sure if the POST is officially supported at Marketo, but it absolutely should be, and if it is, I think the documentation should have that as the default, not the GET, and maybe even deprecate the GET, up to you. Security is more and more on people's minds and this has been flagged in numerous companies. I tried the POST like 2 years ago, and saw that it worked, and have told people they can use that instead - I just told someone else today and I think it might be best to just support this and change the documentation. Thanks for the consideration.
... View more