Server: Desktop login flow NG

[rullzer]

So the login flow we have now works great in most situation. But for example doesn't work that great with special SSO or 2FA methods. Take U2F, Smart cards etc.

For this I would propose an alternative flow that can be used.

Basics

1. user open desktop application
2. user enters url
3. user sees a window that says something like Click here to login in your browser
4. user clicks, browser is opened
5. user logs in and grants access (just like it does now)
   
   
   
   • with all the special 2FA or SSO
   
   
6. Message Please close this window and return to the desktop client
7. Desktop client has obtained the token and logged in

Details

At step 2 above the server will query a capability of the server that tells it what flow to use

At step 3 the client will submit a POST request to <server>/login/ng and obtain

• a polltoken (a long 128 char token)
• the url to open and login <server>/login/ng/flow/<logintoken> this login token is also random (32 chars)

The whole login now needs to be completed within 15 minutes. After that both tokens are invalid and the flow has to be started again.

The client will now regurally (every 5 seconds) do a POST to <server>/login/ng/poll with the polltoken.
Once the authentication in step 6 is successful this will return the

• server
• loginname
• apptoken

Once step 6 is completed the logintoken becomes invalid
Once the server has obtained the authentication details the polltoken also becomes invalid

Advantages

• This allows a user to login to the desktop client as long as they are able to login to the webUI
• This makes sure that we do not have to implement Kerberos/Smartcart/U2F support in the desktopclient
• If the user is already logged in they only have to grant access (and not login).

CC: @MorrisJobke @nickvergessen @ChristophWurst @blizzz @schiessle

[rullzer]

Ah one thing that comes to mind. We need to do some public key stuff to ensure that the apptoken is not stored in plain text in the db.

So

1. generate private/public-keypair at step 3
2. private key is encrypted symmetricly with the post token
3. post token is stored hashed in the DB

This is similar as how we handle the apptokens with public keys.

[ChristophWurst]

/login/ng/poll

How about using a version number instead of ng? For future iterations this will be better.

[nickvergessen]

/v1/ is what all other apis use as scheme