Android-SingleSignOn

Android-SingleSignOn copied to clipboard

I'm currently trying to implement Nextcloud SSO for DAVx5. I can call the account picker, which successfully returns a SingleSignOnAccount with userId and token.

However, this token doesn't seem to work as app-password (= Basic <userId>:<token>) nor as access token (Authorization: Bearer <token>).

I don't want to use the SSO network methods because DAVx5 has its own network stack with very specific requirements.

Should the token be usable as app-password/access token or is there some way to get working HTTP credentials from the SSO library?

The received token is not supposed to authenticate against the Nextcloud server, it is purely local and only authenticates against the local Nextcloud Android app (see Flow Chart).

Maybe an actual token can be fetched using the network stack of the Nextcloud app and used from there?

As a DAVx5 user myself I'd love to see a SSO integration for Nextcloud. As @stefan-niedermann already mentioned it is not possible to use the Token as an Auth-Token with Nextcloud directly. That means when a third party app wants to make a request to the Nextcloud, the requesting app never knows anything about the credentials for the server and thus even if this third party app had bad intentions or some malware got injected they couldn't exploit the credentials for the server as the token only works on the device itself.

Maybe an actual token can be fetched using the network stack of the Nextcloud app and used from there?

Sure, that could be an option - but that would be against the idea of the SSO lib at this point. May I ask what kind of network stack you are using under the hood? I know the whole DAV situation is a little messy (or at least it was ~10 years ago when I tried to take a shot at it..)

that would be against the idea of the SSO lib at this point

It is partially against the idea 😉 The benefit of a better UX remains - however other aspects as same network stack and zero-knowledge about security related stuff are gone this way.

In my opinion better than "nothing" 🙂.

Sure, that could be an option - but that would be against the idea of the SSO lib at this point. May I ask what kind of network stack you are using under the hood? I know the whole DAV situation is a little messy (or at least it was ~10 years ago when I tried to take a shot at it..)

We have our own library: dav4jvm which is based on okhttp. Also, there's much HTTP code in DAVx5 itself (like here, but there are HTTP requests virtually everywhere). We also control things like timeouts, do things on TLS layer (like client certificates), …

If I understand it correctly we would have to change/generalize all okhttp calls, which seems cumbersome and I don't know whether I want it. Also, the Nextcloud app process would have to be active for every synchronization (to pipe network traffic through), which consumes additional resources.

Maybe SSO is just not the correct approach for apps like DAVx5? In the next version we support at least a better Login Flow where you can enter the Nextcloud address, so that you can also use Login Flow when the Nextcloud app is not installed.

Alternatively I could imagine that apps could somehow request "real credentials", and the SSO lib could show an extra warning for the user and then issue an app password or a Bearer token. But I understand that this is still against the SSO lib network concept.

Sorry for the delay - yes - I agree, that integrating SSO wouldn't be a trivial tasks for an app like DAVx5 as some of the features that you probably need are not available yet. So I do agree that an option to "request" real credentials / app password would be a nice addition. Probably something that should be feasible but I'm not sure if anyone has the time right now to implement it. I'm happy to give some pointers and assist though if anyone wants to have a crack at it.

Maybe someone from the App team can give their opinion about this feature as well as this is a feature that would have to be implemented there as well. @tobiasKaminsky maybe?