Core: Client auth detection

[ChristophWurst]

(copied from https://github.com/owncloud/core/issues/24794#issuecomment-222933509)

Authentication mechanism detection

With multiple authentication mechanisms available, clients need to know which one is used to either prompt for for login credentials or open an URL in an external browser.

Auth

These are the auth mechanisms we support:

• Auth1: _old_ auth with basic auth (username, password)
• Auth2: token basic auth (username, token)
• Auth3: pure token auth where token is sent as HTTP header. Not yet supported on DAV

Token generation

These are the token generation mechanisms we support:

• Token1: user generates token on personal settings page
• Token2: send POST request to /token/generate with loginname+password and get a new device token
• Token3: use browser-based authentication in external browser #24835 where the client shows a browser with a URL returned by the server

Possible setups/configuration

These are the setups that we need to support:

• password auth allowed, 2FA disabled
  
  
  
  • Auth1
  
  
  • Auth2 and Token1
  
  
  • Auth2 and Token2
  
  
  • Auth2 and Token3
  
  
• password auth not allowed, 2FA disabled
  
  
  
  • Auth2 and Token1
  
  
  • Auth2 and Token2
  
  
  • Auth2 and Token3
  
  
• 2FA enabled
  
  
  
  • Auth2 and Token1
  
  
  • Auth2 and Token2
  
  
  • Auth2 and Token3
  
  
• external identity provider used (via apache auth, e.g. shibboleth)
  
  
  
  • Auth2 and Token3
  
  

Client detection

We need to find a way for clients to detect which auth mechanisms and token generation mechanisms are supported. As discussed with @PVince81 we think that a special info route could be used to return that info. E.g. the client sends a request to /auth/info and gets a list of auth mechanisms and/or token generation mechanisms it can choose from. That route must be accessible without user credentials.

[PVince81]

@guruz @PhilippSchaffrath @davivel is this still needed with OAuth2 ?

[guruz]

I propose that we return in status.php (unauthed. can't use capabilities which is authed) that we support OAuth2, possibly with an endpoint if needed.

legacy: If this is not returned in status.php we just do the old HTTP auth.

legacy: If status.php is redirect we use Shibboleth/SAML

[davivel]

I propose that we return in status.php (unauthed. can't use capabilities which is authed) that we support OAuth2, possibly with an endpoint if needed.

OK to me.

legacy: If status.php is redirect we use Shibboleth/SAML

This will not work; as you said, status.php is unauthed, so there will be no redirection to the IdP.

For legacy, I would just keep the detection how it is right now. In mobile clients we send an unauthenticated HEAD to the remote.php/webdav.

[guruz]

Sorry, I mixed this up. You are right.

(@ogoffart for review)

[davivel]

In mobile clients we send an unauthenticated HEAD to the remote.php/webdav.

I'll go further. We are using this even to dectect OAuth2 authentication. We expect these types of responses:

• 200 -> no authentication
• 401 with authentication challenge header starting with "basic" -> Basic HTTP Auth
• 401 with authentication challenge header starting with "bearer" -> OAuth2, with bearer token (the only kind of access token we handled in our past POC)
• 302 to IdP -> SAML

[guruz]

@davivel I need to check if Qt gives us control/access to this header :/ It might be abstracted away

[davivel]

Sad to read it, @guruz ...

[PVince81]

@PhilippSchaffrath might be relevant in the context of OAuth2

[ogoffart]

I suppose we can just query the OAuth endpoint and see if it's there. -> Oauth
Otherwise we do as before.

[davivel]

From clients perspective, an important detail is defining the default behaviour when different auth methods are supported in the server, as will be the case in the short term.

If server is OAuth-capable and Basic-capable, should the app default to request OAuth to the user? Will this be a hard request, or will the app allow the user to switch to Basic in the login-view/wizard?

I don't have a strong opinion about it, though in general I prefer let the user some options.

[PVince81]

moving to triage

[PVince81]

Is this still relevant ? How does it currently work with OAuth ?

[michaelstingl]

If capability announces OAuth, then clients use OAuth

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.