Is it necessary to provide consumer key and consumer secret to get access token/make API call

Question

I am trying to update contact record in Salesforce via API call. I got the access token first by providing username, password, consumer key, consumer secret, grant_type. Then I used the access token and made the second call which is the actual API call to update contact.

My question is is it possible to update contact/get access token just with username, password without really providing the consumer key and consumer secret or we definitely need consumer key and consumer secret to get access token/update a record in Salesforce.

This is the API I am trying to access:

https://mydomain/services/data/v36.0/sobjects/Contact/Id/003AU00000MhW3WQAV

Thanks

Answer 1

Is it must to provide consumer key and consumer secret to get access token/make API call

Yes. But only to get access token. Once you have the access token, you don't provide the consumer key/secret in subsequent API calls.

You should take a look and understand how authentication works in case of REST API, documented at Understanding Authentication.

Before making REST API calls, you must authenticate the application user using OAuth 2.0.

And that when you authenticate using OAuth 2.0, the pre-requisite is to have a Connected App by which you will be able to get the Consumer Key/Secret and utilize it further for authentication and getting the access token using your preferred authentication mechanism.

Answer 2

There are a selection of OAuth 2.0 flows, and not all of them require the same information.

The consumer key is always required from what I can see, because that's how Salesforce is able to identify the connected app that you're trying to use.

The client secret, on the other hand, is only required some of the time. In the JWT Bearer flow, for example, you don't use the client secret (and you can set things up to not require passwords either). Instead, you sign the JWT with a certificate that you provide in the Connected App.

If you can get hold of a session id (don't be a jerk and use someone else's, use your own), you should be able to make API calls using that instead of going through the OAuth hoops. I would not recommend deploying a system that relied on this though. I'd just use it for prototyping and/or messing around.