Teleport Connect should offer reauthentication option for confirming device trust for web

[stevenGravy]

Expected behavior:

A user would get a re-login flow option if their Teleport Connect session ended.

Current behavior:

If the Teleport Connection session ended the user gets this error. The user then has cancel, relogin and restart the web device trust process.

Bug details:

• Teleport version: 16.0.1
• Recreation steps

1. Configure a user with trusted device
2. Login to Teleport Connect and allow the session to expire
3. Login via web ui

[webvictim]

+1, just hit this on 16.1.4

[codingllama]

FYI @ravicious @avatus.

[gzdunek]

We forgot to wrap the call in retryWithRelogin, I will fix it.

[gzdunek]

At first I thought it was a trivial issue, but it requires more work than I expected.
The main problem is that the device trust confirmation is displayed in a dialog, so to allow the user to log in again, we would have to replace that dialog with a login dialog (but then we would lose the original dialog).
We have a mechanism for showing two dialogs at the same time (regular dialog and important dialog) but this is reserved for events coming from tsh daemon. As a side note, we should not overuse such a mechanism, as modals are generally bad from a UX perspective.

Because of that, we should the transform the "device trust confirm" dialog into a tab that would be opened automatically.
But first we need to think about how this should work in detail, like whether the tab should automatically close on confirmation.

Unfortunately, I don't have enough time currently to work this, I'm going to close the linked PR as it doesn't solve the issue (although adding retryWithRelogin will be needed anyway).

[codingllama]

The main problem is that the device trust confirmation is displayed in a dialog

Could we decide beforehand what dialog to show? For example, do a ping first then proceed to the "regular" device trust dialog if it's OK, but if it's not we show a login dialog with a brief explanation?

Just brainstorming a few alternatives here, this is not UX advice ;)

[ravicious]

@gzdunek I was thinking about the idea of converting this modal to a tab. I wonder if #48813 enabled other approaches here.

The problem here is that we'd like to show a regular modal (the login modal) while an important dialog is shown (the device trust modal). Converting the device trust modal into a separate tab does address this problem, but from a design and UX standpoint, what are we going to put in that tab? Just the same text and two buttons?

I don't think it's necessarily bad, though it might seem kind of weird, given that we don't do this anywhere else in the app. It'd be good to have some input from the design team, but ultimately I think it's more important to address this problem at all rather than doing it in a perfect fashion UX-wise.

But perhaps expanding retryWithRelogin with some extra option that makes the login modal important would be another option to consider.

---

On top of that, if we don't take any extra precautions, converting this modal into a tab means that data passed from the Web UI to Connect through the custom scheme URL would get saved on disk. Connect automatically saves the state of all open tabs on disk so that it's able to reopen tabs on the next launch.

IIRC, the security model of Device Trust already accounts for this kind of data exfiltration. But it'd probably be a good idea to not persist this particular tab on disk in the first place.

[gzdunek]

I was thinking about the idea of converting this modal to a tab. I wonder if #48813 enabled other approaches here.

But perhaps expanding retryWithRelogin with some extra option that makes the login modal important would be another option to consider.

Yeah, I considered this, but since it sounded like a 30-minute fix, I thought I could focus more on improving the UX :p
Generally, I’m concerned about one dialog opening another. For hardware key prompts and relogin, it made more sense since they were all part of the login process. But here, session authorization and relogin are separate processes.

I can imagine that if I clicked "Authorize session" and saw a login dialog immediately, I could get confused: "What happened to the previous dialog? Is the session authorized? Will I have to repeat the process? Can I cancel it and I will be able to log in later?" Seeing the original action in the background tab feels more safe—you are sure it's not lost.

What's more, the app makes you go through several dialogs when starting:

1. A login dialog if the cert is expired.
2. A dialog to reopen the previous session (IMO we could get rid of this be defaulting to new session and having an option somewhere to restore previous tabs).
3. Finally, a dialog to authorize the web session.

Another issue with a dialog is that showing only error states might look weird in these cases:

• Teleport Connect - Device Trust - Different user logged in #45714 - here we could explain the user needs to relogin as a different user.
• Provide instructions and info on device trust with web #43020 - similarly, when the device is not enrolled we could add instructions what to do.

from a design and UX standpoint, what are we going to put in that tab? Just the same text and two buttons?

Yeah, probably. I know it’s not much, but I believe it could be similar to the Connect My Computer screen, which looks nice (especially the error states!).

Tagging @roraback, do you have any thoughts on this?

[ravicious]

That makes sense to me. 👍

[gzdunek]

Here's a demo of web session authorization in a tab, instead of in a modal:

device.trust.tab.mov

The tab closes automatically with a small delay after the user clicks any of the buttons.
@roraback does this look good to you?

[ravicious]

FWIW, I'd assume that for the majority of the users the browser is going to cover the window with Connect. On success we could close the tab instantly and show a success notification saying something like "Web session successfully authorize". The notification would disappear after 5 seconds anyway.