(High-level) Consideration for OAuth token lifetimes

When choosing lifetimes for OAuth access & refresh tokens, the following three considerations should/may/might factor in:

1. Application sensitivity (the risk of application data being compromised) - the more risk associated with an application, the shorter should be the token lifetimes (all else being equal)
2. Average application usage frequency (how much time passes between separate application sessions) - if an apps gets used only once a month, the appropriate refresh token lifetime will be different than for an app that gets used daily (all else being equal)
3. Average application  session duration (how long a user typically interacts with the native app) - if an app is used only briefly, the appropriate access token lifetime may be different than for an app that is used continuously all day (all else being equal)

If the above considerations are in conflict, risk is likely the more important consideration. In other words:

Tie goes to the (risk) runner 

Overly simplistic Claim #1 - a refresh token only serves a purpose if its lifetime is longer than the average time period between application usages

Apps that are used only infrequently therefore demand longer RT lifetimes - because otherwise the RT would have expired before it was ever used.

But this consideration is overridden by application sensitivity/risk

So, a taxonomy if you will

• Low sensitivity & infrequently used ---> Longish RT lifetime (both push lifetime up)
• Low sensitivity & frequently used    ---> Longish RT lifetime (opposing forces)
• High sensitivity & infrequently used ---> No RT (opposing forces, risk wins)
• High sensitivity & frequently used    ---> Shortish RT lifetime (both pull lifetime down)

Overly simplistic Claim #2 - an access token lifetime should not exceed the average length of time for an app's usage session.


But this consideration will also be overridden by application sensitivity/risk

So, another taxonomy

• Low sensitivity & short usage  ---> Shortish AT lifetime (opposing forces)
• Low sensitivity & long usage    ---> Longish AT lifetime (both push lifetime up)
• High sensitivity & short usage  ---> Shortish AT lifetime (both pull lifetime down)
• High sensitivity & long usage    ---> Shortish AT lifetime (opposing forces, risk wins)

Depending on where your application sits in the 3D array defined by sensitivity, session length, and usage frequency - the above might help you choose values for the access & refresh token lifetimes. 

For instance, for a low sensitivity app used infrequently for only short times , you could consider

1. short access token lifetime (because session length suggests so and risk doesnt overrule)
2. long refresh token lifetime (because frequency suggests so and risk doesnt overrule)

etc etc