1
  1. I have seen a lot of stack exchange posts suggesting that the expiry time of the OAuth access token cannot be determined. It is dependent upon the session timeout policy set at user profile level and/or org level (in that order). The default limit is 2 hours. However, based on this SFDC doc

You can control how long a user’s session lasts by setting the timeout value for the connected app, user profile, or org’s session settings (in that order).

it seems like we can set it up at the Connected App level and it will essentially overrule the settings at user/org level (assuming User session policies determine the token expiration policy). I tried setting it here: Setup -> Manage Connected App -> Manage -> Session Policies -> Timeout Value but it didn't seem to work. Is this even possible? If yes, how?

  1. I understand that SFDC refreshes (extends) the expiry time of the access token once it is used. Is there a max limit on how many times or for how many hours at max that one token will be valid? Or say if the token is being used continuously it can essentially exist forever? Isn't that a security risk?

Update:

  1. Revoked all the existing tokens and got a new access token. The validity still shows 2 hours: Token validity

  2. Connected App settings: App details Manage App section

3
  • I assume that such a change to session timeout would only take effect after you get a completely new token (i.e. wait for the current token to expire or forcibly revoke the token). Have you done that?
    – Derek F
    Feb 12 at 20:10
  • being used continuously it can essentially exist forever - perhaps the docs can be interpreted as such, it'll expire in practice even if you continuously use it. The expiration trigger / cause are undocumented but we've had that happen many times.
    – identigral
    Feb 12 at 21:18
  • @DerekF I revoked all the OAuth tokens from the user profile and got a new access token. The token validity for still 2 hours. Added screenshots with details.
    – tanfive7
    Feb 14 at 9:12

2 Answers 2

0

I think clarification is required for #1, so I won't answer that at this time.

For #2, there is no limit that I'm aware of. If there is a limit to the number of times the session can be extended, I haven't yet encountered it. I believe that one of my external systems has been using the same token for over a year or two at this point (because it routinely makes requests frequently enough).

To be a bit more specific on when session extension happens, I believe the consensus is that it happens if you make a request in the latter half of the token/session lifetime. E.g.

  • if you obtained the token at 6 am
  • with a timeout of 2 hours (so the initial expiry is 8 am)
  • and make a request at 7:30 am (really, any time between 7 am and 8 am)
  • your token will then not expire until 9:30 am

I don't know if that's officially documented anywhere.

As for whether or not it's a security risk, I'd say no. At least, not any more risky than having an external system being able to obtain/use access tokens in the first place. The access token is sent in an HTTP header, and those are encrypted when using Https. So the only way for something/someone else to use a given token would be for it to leak from the client (the thing that obtains/uses the access token), and if an attacker is that far in, then they'd already have the ability to get a new token anyway.

0

[...]but it didn't seem to work. Is this even possible? If yes, how?

Yes, it does work. Keep in mind that your session is refreshed periodically when you use it. Check Setup | Security | Session Management to determine when a session expires. Try waiting until after it should time out and try it, it should work as expected.

I understand that SFDC refreshes (extends) the expiry time of the access token once it is used.

That's correct.

Is there a max limit on how many times or for how many hours at max that one token will be valid? Or say if the token is being used continuously it can essentially exist forever?

There is no limit to long long the session will last, as long as you're using it regularly.

Isn't that a security risk?

There's no extraordinary risk to having a session be active while you're using it. After all, an attacker would have first already logged in, in which case they have your username, password, and MFA, or Lightning Login device, etc. So, your session is at least as secure as your devices are.

That's not to say you can't mitigate the risk. Encrypt your hard drive and require a secure login, lock your devices when not in use, etc.

1
  • I added screenshots to the post. Even though the session timeout is set to 15 mins in the connected app, the token validity shows 2 hours. Am I missing something? Is there some other setting in the connected app that needs to be done to override the profile/org's timeout policies?
    – tanfive7
    Feb 14 at 9:20

You must log in to answer this question.

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