4

I am now using web server authentication flow along with refresh token flow in my system. Once a user granted a permission for the app to access, the app will request a permission, an access token and refresh token. Web server authentication would be required only once. Both acquired tokens would be stored and the access token would be refreshed if expired.

Is this a good practice? Should web server authentication flow always be used with refresh token flow? When should we use refresh token to get the access token anew?

Is it acceptable to just use web server authentication flow every time to get a new authentication code and a new access token? Because the user logs in process seems to be skipped if the user has already granted the permission to the app.

Any guidance would be much appreciated!

Improve this question

1 Answer 1

Reset to default
1

What I have done in that situation is the following:

Basically I have 2 methods - 1 uses the access token to make calls (if access token is present) and another one that uses the refresh token if the access token is not present or session has expired, to obtain a new access token.

At first I always try to use the access token, assuming it's still valid. If that fails, I am calling the 2nd method that uses the refresh token to obtain new access token and if that one fails for X reason, then I'm just redirecting the user to the normal login screen. If a new access/refresh token is returned in a success case, obviously I'm storing the new tokens and use them in the future.

I haven't seen best practice documentation around these scenarios yet but I reckon you should be always trying to use the access token first.

Improve this answer
7
  • 1
    Thank you for the reply. What you mentioned above is exactly how I implemented my system. But since I have learned that web server authentication flow would skip the user logs in process once the user granted the permission, I developed an idea that, if I used only web server authentication flow each time to get a new authentication code and, later, the access_token, there would be no needs to store the access_token and refresh_token to my system for the later usage. But my idea might be an unhealthy approach because Refresh Token Flow exists and it might exist for some purposes.
    – lw29
    Commented Jul 3, 2014 at 1:05
  • 1
    It makes sense, though I haven't heard anyone or read any documentation regarding best practices, and what you should or should not do when using particular flow. Talking from general authentication point of view, you should always be using the time to live or session time for the current token. If you have X reason to authenticate every time, I don't see a problem unless you are releasing a managed package that needs to go through a security review...
    – Boris Bachovski
    Commented Jul 3, 2014 at 1:10
  • 1
    Oh if that's the case - once a month frequency, then you should be definitely using the web server flow. Even username+password flow would work in that case.
    – Boris Bachovski
    Commented Jul 3, 2014 at 3:36
  • 1
    Refresh token expires eventually too, but there is no set time to live for that token I believe. It says that lives a lot longer than the access token, but I haven't found out exact time as yet. In case it expires, you'll need to re-authenticate obviously and you need to cater for that scenario, as you said, it can be revoked from within SF :)
    – Boris Bachovski
    Commented Jul 3, 2014 at 5:10
  • 1
    Thank you! I will definitely add the expiration check to the system.
    – lw29
    Commented Jul 3, 2014 at 5:24

You must log in to answer this question.

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