Over a million developers have joined DZone.

Mule OAuth2 Support: Even Easier Still

DZone 's Guide to

Mule OAuth2 Support: Even Easier Still

· Integration Zone ·
Free Resource

This post is brought to you by… you! Yes, a couple of weeks back I was writing about how dealing with OAuth2 secured APIs got way easier since Mule’s August 2013 Release. We got such a great feedback that we decided to incorporate some of it in our latest October 2013 release.

Token Management vs. Token Nightmare

So let’s do a quick recap. In the last post we said that now Mule is way smarter at automatically handling your tokens. So, in a single tenant scenario you could just do this:

<sfdc:authorize config-ref="mySalesForceConnector"/>
<sfdc:query="...." config-ref="mySalesForceConnector"/>

In this case, Mule will automatically handle your tokens by using the connector’s config name (in this case “mySalesForceConnector“) as the token id.

This is not enough for the multitenant case, since different tenants need to have different token ids (otherwise user1 could end up entering user2′s account and everything would be a big mess). So, we added the possibility to force a token id while doing authorization. The same example would look like this:

<sfdc:authorize accessTokenId="#[message.inboundProperties['tenantId']]" />
<sfdc:query="...." accessTokenId="#[message.inboundProperties['tenantId']]" />

This is great and a huge improvement over Mule 3.4.x. However, imagine a reeaallly large app in which you make extensive use of the Salesforce connector and your token id could always be obtained by the same expression (in our case #[message.inboundProperties['tenantId']]). In such an scenario, it would be quite annoying having to repeat the same expression in every single message processor. Not to mention that if for any reason that expression changes, you would have a lot of places to modify.

Repetition: Worst thing can happen to an artist

So yes, the problem here is repetition. Nothing like a good old default value to fix this. So basically, the big little change in BigHorn is this:

<sfdc:config name="mySalesforceConnector" consumerKey="${consumerKey}" consumerSecret="${consumerSecret}">
	<sfdc:oauth-callback-config domain="localhost"
		localPort="8081" path="callback" remotePort="8081"

<flow name="myFlow">
	<sfdc:authorize />
	<sfdc:query="...." />

This is how it works:

  • Each time an OAuth2 protected operation is found (and this includes the authorize) we check if the message processor has its own accessTokenId expression. If it does, we evaluate it and use it.
  • If the message processor didn’t provide its own token id, then we look for the default. If there is a default, then we evaluate the expression and use it.
  • If no defaultExpression was found either, then we just use the connector’s config name.

Neat isn’t it? But that’s too much XML. Can I do this in Studio? Sure! He’re is how:

So, nothing more to say than thank you! This is a feature straight from your feedback. If you have more, please bring it on!


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}