Does Marketo provide any advance authentication methods beyond basic? I was not able to find any reference to any advance methods and want to make sure I am not missing anything. Thank you.
Solved! Go to Solution.
With the authentication do you mean REST API authentication? Is so then Marketo’s REST APIs are authenticated with 2-legged OAuth 2.0. Client IDs and Client Secrets are provided by custom services that you define. Each custom service is owned by an API-Only user which has a set of roles and permissions which authorize the service to perform specific actions. An access token is associated with a single custom service. Access token expiration is independent of tokens associated with other custom services that may be present in an instance.
Refer here!
With the authentication do you mean REST API authentication? Is so then Marketo’s REST APIs are authenticated with 2-legged OAuth 2.0. Client IDs and Client Secrets are provided by custom services that you define. Each custom service is owned by an API-Only user which has a set of roles and permissions which authorize the service to perform specific actions. An access token is associated with a single custom service. Access token expiration is independent of tokens associated with other custom services that may be present in an instance.
Refer here!
Thanks @Darshil_Shah1 . It is definitely beyond my technical knowledge, but I understand there is a Certificate based Authentication method. I am trying to understand if this has been explored by any community members.
Client cert auth for the REST API? Nothing like that is documented, like Darshil says it's OAuth Bearer (which is not Basic).
@Aslihan_Ayan_Ha can you clarify what service you were referring to - the REST API or something else? I'm not aware of any part of Marketo that uses Basic auth, now that I think about it.
@Aslihan_Ayan_Ha do you still have an open question about this? Like Darshil said, the REST API uses Bearer auth (not Basic) so it isn't clear which area you're wondering about? You could mark Darshil's answer as the solution if this is resolved.
@SanfordWhiteman , Sorry about the delay. I checked in with my internal team and understand that I was not structuring the question correctly. The specific feature they were interested in was around Webhooks. And know they are exploring the options based on:
OK.
Well, webhooks are stateless. That means a webhook definition needs to have built-in credentials, because it can't, by counterexample, use a separate identity endpoint to get a valid access token or anything like that.
Those credentials could be in the Authorization header, or in a custom header like X-Api-Key, or in the URL query string, or in the POST body - and could be stored in a {{my.token}} - but whatever they are, they must be known at the time the webhook is executed.