What is the utility of token refresh?

I do not understand the reason for the token refresh. According to this:

https://www.ecobee.com/home/developer...

Access tokens are valid for 1 hour while refresh tokens are valid for 1 year. To be able to refresh access tokens every hour I need to save refresh token in my application. Let us see what are the potential risks:

1. Somebody sniffs traffic between my app and Ecobee API. This is highly unlikely as API uses HTTPS! They can steal access token, but it will expire in 1 hour. However, if they just wait long enough (1 hour) my app will issue a refresh token request (over the same channel) which they will sniff. Now they have refresh token which they can use for 1 year to get a new access token.

2. Somebody hacks my app secure storage where it keeps token. The attacker will have access to both access and refresh tokens. Even though access token will expire, it could be re-generated using refresh token.

Frankly, I do not see any added security here.
1 person has
this question
+1
Reply
  • 1
    A refresh token is only valid for one year if it's not used. Since the access token expires every hour it has to be refreshed, which also refreshes the refresh token. I believe this is so that your app does not have to be running constantly, updating tokens every hour without fail, in order to avoid having to perform a new PIN authorization. So your app can be offline for up to a year, but the refresh token you stored on the client side can still be used to obtain a new access token when you run your app again. If someone steals your refresh token and uses it (but they need your private app key as well, so keep it safe!), they would have to do so while you're not using it. And like you said, this is all being conducted over HTTPS, so vulnerabilities are quite unlikely.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • 1
    Hi,
    Read carefully below URL ::
    https://www.ecobee.com/home/developer...

    John Cocula also explain good.

    Refresh token handle by back end coding and using refresh token you can generate new authentication token for every hour.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • I understand how these 2 tokens work. I do not see how this mechanism improves security, compared to, say, single non-expiring access token.

    The only scenario I can envision where it might help is when traffic between client and server was sniffed but for very short period of time (less than an hour), so intruder only intercepts access token but not the refresh token. First of all, this is very unlikely, given HTTPs transport. Second, if we try to imagine real-life attack scenarios for such short-term intercept, it will too look improbable.

    So, in my opinion, the whole dual token mechanism with refresh adds a lot of work for API clients without much benefit. Unless I am missing something here...
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • 1
    Here is some discussion about it, under the heading "How the system with long-lived refresh token and short-lived access token should work".

    https://stackoverflow.com/questions/3...

    In short, access tokens can be signed and self-contained and don't need to hit the database to determine their validity, whereas refresh tokens are tied to the client's credentials and thus do need to hit the database to verify them (and they can be revoked). I don't know if Ecobee made use of these efficiencies, but I would be surprised if they didn't.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • I accept the performance argument, although I thnk that such performance optimization should be handled on the server side without burdening users with 2 tokens.

    For example, I am writing a small server-side program which periodically (few times an hour) pulls data from the thermostat. Now I need to:

    1. Store access token
    2. Store access token expiration time
    3. Store refresh token

    Before doing a request, I need to check if my access token is still valid. If it is not, I need to:

    1. Refresh it
    2. Store new access token
    3. Store new token expiration time
    4. (It looks like a new refresh token could also be issued during the refresh so I might need to store it as well)

    Only then I can make my request.

    During all these operations I need to handle timeouts, errors, clock skews, write data to disk (store tokens). It is a lot of work for such simple API, given that there is no added security benefit.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • MarkK (API Architect) December 02, 2016 16:30
    There are a lot more implications to not having refresh tokens. I'll leave that as a google search exercise for you though.

    You do not need to track the time of token expiry at all. All you need to do is handle the "token expired" error when you make your API request, refresh your token, and make your original request again. That can be simply handled in a central handler.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated