We have a process creating Salesforce leads. The process is server-side and automatic. As a result there isn't a Salesforce user nor a browser for traditional OAuth.

What is the most appropriate authentication method?

I think it is User-Password OAuth Authentication but was surprised that the server process will need two sets of credentials client id/secret and username/password. It will also need to handle session timeouts. I was expecting a single api key/secret without expiry.

2 Answers 2


If you want it to be perpetual, then you have to use the web server flow and keep a refresh token.


It does mean that your admin will have to go through the process in a browser once to get all the tokens into your server. Once you've done that, though, you're fine forever until someone manually revokes the token in SF.

You'll have to handle the fact that your sessions will still expire, but you can use the refresh token to get a new session without any more human intervention.

  • Can the refresh token be used indefinitely? i.e. deploy the service with the refresh token and let it obtain access tokens as needed
    – Brian Low
    Mar 1, 2018 at 22:03
  • 1
    More info on refresh token expiry: salesforce.stackexchange.com/questions/65590/…
    – Brian Low
    Mar 2, 2018 at 2:08
  • Thanks for the extra info Brian. I've not had the problem of a refresh token expiring as in the question you linked to, but that's good to know. Seems like you can still use the web server flow to keep a perpetual refresh token, you just need to be careful not to request extra, unneeded refresh tokens.
    – Aidan
    Mar 2, 2018 at 9:38

Another option is the JWT Bearer flow. I went into some pretty fine detail on the JWT Bearer flow in this other question

The setup is arguably more involved than the web-server flow.

  • You don't need the client secret, but need an SSL certificate instead
  • The process of constructing the JWT (JSON Web Token) is fairly involved
  • You need to use a flow that generates a refresh token at least once before the JWT flow will work

One of the nice things about this flow is that you can specify a specific user to make requests on behalf of, and you don't need them to explicitly authorize the connected app. This is incredibly powerful, so exercising caution is wise. In my case, my org has a general "system" account that we use for things like integration. I don't have access to this user's email, or its password, but I don't need it.

Instead, Salesforce provides the option for administrators to pre-authorize users with certain profile(s) (which are selected by an admin).

For the JWT flow (haven't tried with other flows), while your sessions will still timeout, if you send a request before your session times out, the timeout will be reset (if current time is 08:00, timeout is 2 hours, and I send a request at 09:00, the session will now timeout at 11:00 instead of 10:00).

You must log in to answer this question.

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