Salesforce oAuth token reusability
Hello Belgium ! ‘WHY’ is it this way?
Disclaimer : this one is a little technical. If needed I’ll be happy to provide deeper code details if requested…
The other day I got a requirement from my client. From a usability stand point, it was totally understandable !
Usecase :
When a user logs into Salesforce, he receives a token form an external IAM. Using an OpenID protocol, we get a Token that can be re-used to query other systems.
For example, assume a user Mark logs into Saleforce by receiving a token from its Azure Active Directory. That Active Directory also manages access to the corporate Sharepoint. Hence the access granted to connect to salesforce could in theory be also used to interact with Sharepoint on behalf of the user.
The reason why it needs to be on behalf is the Security Audit Complience. Indeed with GDPR, PCI and other security measures, we need to ensure that we log who made a request (CRUD) to the other systems and this, not only in salesforce, but in the other system itself !
Salesforce Standard Methodology
Salesforce provides the Auth namespace to support this requirement. In theory, if you use a standard Auth Provider, you could retrieve the token received by Auth.getAccessToken(String authProviderID,String providerName). As such you query the token received and pass it in your request to the other system you want to target.
This seems like a great news, but to be honest, I never managed it to work correctly. It is not stable and most of the time the methods returns null
WHY? Main problem of this method is that it is is Obscure. And I weight my words ! The second argument asks for the providerName, but it is impossible to know where this values comes from ! Documentation even warns you that it is a strange value :
Note that querying the ProviderType field on the AuthProvider object sometimes returns a value that differs from the expected provider name value. For example, for Open ID Connect providers, OpenIdConnect is the ProviderType value for the AuthProvider object, but the expected providerName is Open ID Connect.
Allright ! That helps a lot (not) ! Under the hood is probably a map<String, <String, Object>> thus if you don’t have the two keys, you won’t get any results. Moreover as this is a private map of the Auth namespace. Thus currently we cannot ask to the system ‘hey, I have this AuthProvider ID, would you be so kind to give me the available values for providerName?
How to make it works then?
I ended up re-writing the entire OpenID protocol with the help of the AuthProviderPlugin Interface. At least they provide some tools to support you. The main problem I faced was the step where you need to get the token afterwards. We (yes because on this one my colleague really had a brilliant idea) is to store the token in a Platform Cache partition.
Overkilling ? Maybe ! But at least we have it all together ! We now a have control on how to request token, where it is stored, what value it contains ! Moreover, we are able, with fine grain configuration, to have specific scopes for that token with a single method !
Beyond just token, simplify life of your users
And BOUM ! Right there we had an incredible opportunity! Have you ever read the way users are supposed to connect to an External Datasource with
Authentication Settings for External Systems? What a pain !!! As you know where your token is located, you can bypass this quite un-userfriendly way to connect to the external database, by re-using the token delivered during login and pass it to the external data provider. (yes we had to use the DataSource interface to allow this, but user experience increased by a lot !)
Final words
If you have input on how to deal with this in a much simpler way I’d love to hear about it. Single Sign On and multi system integration is key in companies ecosystem. Hence a STABLE way to ensure traceability across systems becomes mandatory !
