I have external data source configured in Salesforce, it connects to OData 4.0 API. Let's say I have 1 external object in this data source, called Kitten. The problem: I want security to be handled on the backend API side, so each API call needs to be accompanied by some kind of Salesforce user identification.

For example: when user "John Doe" creates a new Kitten, the API request sent by Salesforce Connect OData 4.0 connector needs to include information identifying user "John Doe", preferably his Salesforce ID (e.g. a00000000ABCABCABC).

What I tried: in external data source configuration, I set "Identity Type" to "Per User" (so each request is bound to the user performing the action). As for "Authentication Protocol", "Password Authentication" is useless because it sends basic HTTP auth header with user/pass pair that the Salesforce User sets up for this particular connection.

So I tried OAuth 2.0, which seems to make most sense. I created a new Auth Provider of "Salesforce" type, with default values in all optional fields.

Now as a user I configure access ("Authentication Settings for External Systems" in "My settings"), grant access and voilà - now API requests made by Salesforce on this user's behalf contain auth header: authorization: 'Bearer 00D1N00****blah*blah******'

Here's the problem - what do I do with this token to find out which user is making this particular request? I tried using it to connect to the UserInfo Endpoint (https://login.salesforce.com/services/oauth2/userinfo), but I'm getting a response of "Bad_OAuth_Token".

I'm trying not to ask too specific a question here, because maybe the solution I'm struggling with is not the right way to do it. Any clues?

  • 1
    This question is very well asked. You describe clearly what you are trying to achieve, then how, then where you are stuck. And it's a good one besides. +1
    – Adrian Larson
    Commented Apr 18, 2018 at 14:20
  • The one thing that seems off is it should be Authorization, not authorization. I think these headers are case-sensitive.
    – Adrian Larson
    Commented Apr 18, 2018 at 15:14
  • Thanks for your comments, answer was trivial, I feel a bit ashamed now :) Commented Apr 18, 2018 at 15:17
  • That worked? If so I can post it as an answer. I puzzled over it for a while, certainly nothing to be ashamed of! Sometimes, you just need another set of eyes.
    – Adrian Larson
    Commented Apr 18, 2018 at 15:18
  • No, the header was not the problem, the endpoint was... Commented Apr 18, 2018 at 15:20

1 Answer 1


Well, the solution was trivial. I was trying to use default login endpoint, turns out I should have been using my org's domain. So getting UserInfo is as simple as sending a GET request to:


With either Authorization: Bearer TOKEN header or access_token=TOKEN GET param.

Edit: well another problem is that this token doesn't live very long, but I'll have to figure out refresh cycle another day.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .