owncloud
Add tests for all auth and access token refresh flows
This is a follow up ticket for #7072.
We have fixed every auth and access token refresh scenario that we could come up with:
- oCIS / oidc with refresh token (i.e.
offline_accessin requested scopes) works - oCIS / oidc without refresh token (i.e. token renewal via iframe) works
- oCIS / oauth2 with refresh token (i.e.
offline_accessin requested scopes) works - oc10 / oauth2 without refresh token (i.e. token renewal via iframe) works.
It's pretty cumbersome to set up all the environments and test everything manually. To give us more confidence in changes - especially when updating oidc-client-ts, we would like to have acceptance tests that test all of the above flows.
Expected behaviour
Tests fail when something breaks with the lib we're using or the way we're using it.
Actual behaviour
Code paths can break without tests failing.
@fschade @ScharfViktor @phil-davis @individual-it do you have ideas how to achieve this with playwright / the e2e test suite?
As a side note: The access token lifetime is currently hardcoded in both the oauth2 oc10 app and the idp service in ocis.
@individual-it since e2e tests will be done by owncoud themselves for now. So putting this to backlog.
Would still be super nice, yes. Basically as a regression test for the whole token renewal flow.
We currently support ocis with oidc and either with or without refresh token. From the original description, test that:
- oCIS / oidc with refresh token (i.e. offline_access in requested scopes) works
- oCIS / oidc without refresh token (i.e. token renewal via iframe) works
The access token timeout can be configured via IDP_ACCESS_TOKEN_EXPIRATION (in seconds) for the built in idp. Don't go below 30 seconds.
Do you have capacity to work on this @saw-jan ?
We need to know what these flows mean:
oCIS / oidc with refresh token (i.e. offline_access in requested scopes) works oCIS / oidc without refresh token (i.e. token renewal via iframe) works
Should we have to configure web to achieve either of the above behavior? which is the default? or both works at the same time? What type of test scenario/flow is best suited for this?
- login
- do something
- wait for token expiry
- do something
Adding offline_access to WEB_OIDC_SCOPE should get you refresh_tokens and is iirc/hopefully all you need to enable its usage in oC Web
By default offline_access is not in the requested scopes, so first mentioned scenario is the default behaviour (no refresh token => token renewal will happen with the currently valid access token just seconds before it expires).
Like @dschmidt wrote, adding offline_access to WEB_OIDC_SCOPE will cause web to have a refresh token, so that it can obtain a new access token even if the current access token expired. That's the second scenario.
For both scenarios:
- login
- do something to confirm that the login worked (e.g. create a folder in the web ui)
- wait for token expiry (both scenarios will obtain a new access token)
- do something to confirm that the token renewal worked (e.g. navigate into the folder)
On top of that, for the second scenario (with offline_access / refresh token) it would be great to have an additional test that navigates away from web entirely and comes back after the access token has expired to validate that a new access token is obtained. Validation can again happen by navigating into a folder or whatever else is easy as an action that requires authentication.
Maybe that's obvious anyhow, but it would be great to somehow validate that the right mechanism was used. What I'm saying is: that the page still works after token timeout in itself does not guarantee that iframe or refresh token mechanism were used (except for the "on top case" @kulmann brought up), so it wouldn't catch a bug in our code that accidentally completely disables token refresh mechanism e.g.
Maybe that's obvious anyhow, but it would be great to somehow validate that the right mechanism was used. What I'm saying is: that the page still works after token timeout in itself does not guarantee that iframe or refresh token mechanism were used (except for the "on top case" @kulmann brought up), so it wouldn't catch a bug in our code that accidentally completely disables token refresh mechanism e.g.
So basically the "on top" case for the first scenario, but this time having the test succeed if the user needs to login again after navigating back to web? :-) Or do you want to have checks that go down into the business logic of oidc-client-ts?
I'm not sure how we can test it meaningfully - but in doubt maybe we can check for the presence of the iframe or something like that.. otherwise it's probably hard to know which endpoints of the IDP have been used, dunno