OAuth2 token revokation does not expire sessions

[jesmrec]

Steps to reproduce

1. Create a new OAuth2 session:

2. Remove the authorized OAuth2 token in webUI Security section

Expected behaviour

Sessions for this client/user agent are removed/invalidated as well

Current behaviour

Sessions keep alive, all request are reponsed with 200

Set up:

• ownCloud 10.0.4 RC1 (daily) Build:2017-12-01T04:16:36+00:00 d4eab96823baec0061bc221e35b49dce968cbed9

• OAuth 0.2.1

[PVince81]

@DeepDiver1975 @pmaier1

[Dagefoerde]

Why do token-authenticated requests even create a session? I'd expect token-authenticated requests to be (rather) stateless, as the token is transmitted with every request. Therefore I think that such requests should not result in a session in the PHP sense at all, since that could be used to circumvent the token.

[DeepDiver1975]

@Dagefoerde you are absolutely right - this is some technical dept about the session handling ....

[DeepDiver1975]

ok - there is an issue in UserSession::verifyAuthHeaders - not all scenarios are covered .....

[SamuAlfageme]

Yup, I'll suggest moving this to core since "client-associated-session revocation" does work out of the box. For individual session revocation (not yet supported) refer to #97

Core is both generating a valid cookie (like @Dagefoerde pointed out in #103 (comment)) and also accepting it (i.e. not ignoring) as authentication mechanism. A client sending both, an expired/revoked auth. token and this cookie therefore continues working normally. The same would apply for other stateless/token-based methods (e.g. app. passwords)...

[PVince81]

So next step is owncloud/core#29779 ?

[jesmrec]

should be. At least, OAuth2 does not have to handle cookie sessions. The validity of the token should be enough to determine if the client is allowed to perform actions.

[michaelstingl]

@PVince81 quick-fix: just drop the sessions?

[PVince81]

@DeepDiver1975 can we do a quick fix and drop the sessions only for oauth, not in a broader scope ? (the broader scope needs more discussion)

[PVince81]

The code must likely be added here: https://github.com/owncloud/oauth2/blob/master/lib/Controller/SettingsController.php#L177

I had a look at the DB structure and it seems we don't have a mapping between OAuth token and sessions.
However it is likely that core's DefaultTokenProvider also stores an entry in "oc_authtoken" that uses the OAuth token as password. So this entry could be invalidated explicitly in the above code.

[SamuAlfageme]

I'd set the expectations for this as "remove and invalidate the orphaned sessions created when using OAuth" as Auth8N method, as:

I'd expect token-authenticated requests to be (rather) stateless, as the token is transmitted with every request.

...is yet not possible considering the cookies are required for some core features to work IIRC (correct me if I'm wrong @DeepDiver1975)

Sessions keep alive, all request are replied with 200: Success

This is the part not reproducible as for today (10.0.6) - in contrast with the similar: owncloud/core#28553. We should recap everything sessions-related to work towards the same goal.

[SamuAlfageme]

Relabeling because of owncloud/core#30365 (comment) -> moved to mobile team backlog.