REST API Salesforce Identity URL fails with 404 No_Access error (How to use admin user to read other user's information such as email_id?

Question

I am using Salesforce REST API fetch the list of log files and getting events/records from each log file. I have generated oauth2 token successfully. Using token I can query list of log files and can see contents of each log file as well.

But when I use identity URL to get the non-admin user's Email Info it fails with 404 ERROR (No_ACCESS) e.g. https://login.salesforce.com/id/org_ID/user_id

How can I use the access token to see other user's email info ? What settings I need to check for connected app ? How can I allow admin user to read other user's info via REST API ?

Please guide.

I have used following steps to access the IDentity URL: I have used following steps to get the access token.

curl --request POST 'https://login.salesforce.com/services/oauth2/token'
--header 'Content-Type: application/x-www-form-urlencoded'
--data-urlencode 'grant_type=password'
--data-urlencode 'client_id=<consumer_key_connected_app>'
--data-urlencode 'client_secret=<consumer_secret>
--data-urlencode 'username=<system_admin_user>'
--data-urlencode 'password=<password+security token>'

This gives me access token without any issues.

But the same access token when used with identity URL:

curl --request GET 'https://login.salesforce.com/id/ORG_ID/USER_ID'
--header 'Authorization: Bearer <ACCESS_TOKEN>'

Returns 404 error saying No_access.

Tried with WORKBENCH and same Identity URL works fine. So what's the difference between WORKBENCH and REST API access ?

I think I am still missing something. Please help.

Answer 1

The access rules are as follows:

• The OAuth request for the access token includes the full or api scope.
• The access token is for a user with the API Enabled permission.
• The access token is for a user who has access to the other user according to the user sharing rules of the org.
• The access token is for an internal user, meaning the user_type value in the response is STANDARD.

Assuming you meet these conditions, it should work. I just tested this in my org and got the expected response, so it certainly should be possible.

Alternatively, you can access similar data via /services/data/v51.0/sobjects/User/:user_id, but it'll have a different format.