As you know, I’ve been encouraging API gateways for years. But Marketo users rarely take up the challenge. In turn, there’s no pressure on Marketo API consumers to build their products to be compatible with gateways.
One fundamental incompatibility is when a vendor lets you enter your Munchkin ID, but doesn’t let you enter a full hostname (or override the default hostname). This signals that they’re hard-appending .mktorest.com after the Munchkin ID, ruling out any rerouting via your gateway.
If you can get past that blocker (which is a very simple code change if they’re willing to make it) then:
Would there be 2 authentications, first against the proxy and then against Marketo?
Ideally, yes.
But you can use a header-based, non-expiring token to authenticate to the gateway, like the X-Api-Key header used by AWS API Gateway. A separate OAuth flow for gateway auth, and having them manage the Marketo OAuth flow at the same time, would be a bit much IMO. (But see below — it’s possible to publish only one OAuth flow.)
Authenticating to the gateway is critical for fine-grained rate limiting, which is the main reason I’ve been telling people to use API gateways w/Marketo — so a single API user can’t run away with all your API calls for the day.
Can 3rd parties generally handle this extra layer of authentication? Or would the proxy have to behave 100% transparent to the service (generally speaking)?
Depends.
Custom code and/or a highly maintained app and/or a highly flexible REST connector that just happens to be connecting to Marketo: absolutely.
Large, slowly evolving commercial codebase: probably not.
If you don’t require any additional headers, you just need them to support a hostname other than {:munchkinid}.mktorest.com.
Is it even "thinkable" to leave it "open" to the wild evil internet and only let Marketo handle the auth whilst the proxy only does basic "throttling" (and whatever else can be done to prevent bad stuff from happening)?
Yes. You could do IP-based throttling this way, yes (a simple config).
You could also build a totally transparent auth proxy without expecting them to do anything other than (what they’ll see as) standard Marketo OAuth. Here’s how that works:
- you don’t tell them their Marketo OAuth creds
- you internally map between API gateway OAuth creds and their “real” next-hop Marketo creds
- they auth only with API gateway creds, using exactly the same path (/rest/identity) Marketo uses, so it works with their existing code
- API gateway creds manage rate limits and so on
- then you exchange the gateway creds for a Marketo creds and get a real Marketo token, but all that is hidden with the gateway
- they continue to make calls to the gateway, and you can even change/restrict the payload before forwarding to Marketo
Would that make any sense at all, or would it be the same as dropping the IP restrictions in the first place?
It could still make sense.
For one thing, you could restrict people to certain payloads, which Marketo alone won’t let you do. Random examples: [1] only let an app dedupe by Lead ID, blocking them from inserting a new lead by Email Address; [2] don’t let an app read all fields on leads, just certain fields.
For another, you could still let only a particular set of Marketo credentials connect to this API gateway. So everyone else would still be subject to the IP restrictions. Specific apps could be forced through the API gateway.
Can I use the words gateway vs proxy interchangeably?
Yes, an API gateway is a reverse proxy.
.png)