Document and officially support POST for API authentication

[Kurt_Koller]

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".

https://developers.marketo.com/rest-api/authentication/#using_an_access_token

https://developers.marketo.com/rest-api/endpoint-reference/authentication-endpoint-reference/#!/Iden...

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=<clien... 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.

[Kurt_Koller]

The RFC for OAuth 2.0 is pretty clear:

https://tools.ietf.org/html/rfc6749#section-3.2

   Since requests to the token endpoint result in the transmission of
   clear-text credentials (in the HTTP request and response), the
   authorization server MUST require the use of TLS as described in
   Section 1.6 when sending requests to the token endpoint.

   The client MUST use the HTTP "POST" method when making access token
   requests.

It seems that POST should be supported officially, and GET should be deprecated and eliminated.

[Kurt_Koller]

This has been added to the documentation and is now officially supported. This can now be closed out, I don't see a way to do it.