OAuth 2.0 Access Token - How to detect User or Application Inactivity

[soccer88]

In many scenarios you'd like to expire the session if the user is
inactive for certain period of time, or to extend the life of the
session if the user is still actively working with the application.
The common implementation for this on a typical web application is to
update the session token (or cookie) with every request. (adding a
'last activity timestamp' to the token)

Given that OAuth (bearer token) doesn't follow this model, what are
the work arounds you have seen to handle this?

The example I'm trying to design around is:

1) User logs in and receives an OAuth access token (set to expire in
30 min)
2) User got distracted and is idle for 25 min, then starts working
with the application
3) In 5 minutes the access token is expired and the client application
needs to resubmit for new access token

I realize that there is a refresh token in some oauth flows.. but in
the 'Implicit' flow per the specs, there is no 'refresh' token.. So I
wonder how to tie the user activity/inactivity with token expiration
using oauth implicit flow? and without the need to store credentials
on the client.

[David Skyberg]

Part of this stems from the fact that an OAuth 2 access token is not
directly related to a user session. The client application receives
both the access token and the refresh token (if being used), but not
necessarily anything specific to a user session. Of course, you can
include user info in the access token attribute set. But that doesn't
necessarily imply the ability for the Resource Server to know how to
validate the user's login session.

You might take a look at how OpenID Connect is addressing this
specifically through the addition of an ID token and session info.
While the specs are not yet fully baked, it does promise to add an
identity layer on top of OAuth 2 that may help resolve these types of
issues (assuming I understand your issue!). If that works for you,
you would have a standards based way to address session management
within OAuth2 use cases.

[Daniel Roop]

We are trying to leverage the OAuth Refresh Token in combination with scopes.  It isn't an ideal state, because it isn't really tracking activity, but we basically have scopes that timeout after not refreshing for a certain period of time.

This doesn't seem to address your concern with the 'implicit' flow, but it was always my assumption that a server supporting 'implicit' flow would leverage the user-agents native abilities to track session (like cookies in a browser situation).  I never really looked but I assumed facebook just checked their normal facebook session cookies, since the request is going to their domain they would be sent.