Evaluate Auth Approval Form

[wesleyboar]

Overview

The token auth approval after login is unexpected for Core Portal user. Is it necessary? If so, then why so many steps (checkbox and button)?

To submit login, and then be asked to do more, is confusing. In typical user interfaces, after username and password are accepted, login is complete. But at TAPIS, it is apparently not.

As a user, if I enter my username and password, and press login, I want to login. If a token is required to do that, why does user care? If user does not approve, then they cannot login. And they only submitted login form in order to login. And after submission, think they are done, yet they are not.

Please help me understand. There may be a way to simplify this user experience, but I am not confident to propose changes until I understand the reason for the current experience.

prod.	dev.

🆕 Proposal

Add the branding at the top of the form (to increase trust) and change layout to:

{% if device_code %}	no device_code

[wesleyboar]

I see now a conditional TTL field "Time for token to live in days (default: 30)". If that field is present, then I understand how this became a separate form. Without the field, the user experience is still unexpected.

[wesleyboar]

Even with the TTL field, I support C.J.'s (private) suggestion to change:

• from [✓] Approve and [ Submit ]
• to just [ Approve ] [ Authorize ]

[wesleyboar]

In #49, I propose:

• fix to layout bug with TTL and [✓] Approve
• new style for the TTL field

[joestubbs]

In general, I am very much in favor of simplifying the flow whenever we can. Specifically, the proposal to remove/combine the Approve box and Submit button into 1 input makes sense.

One thing to keep in mind is that the authorize/approval screen function is somewhat orthogonal to user authentication; once the user authenticates, they have an active session which can live on for hours or days, and during that time they can be shown multiple "authorize" screens because this screen is shown per client application. The idea is that the user is authorizing (or approving) a third-party application to take actions on their behalf. The client application could be the main DesignSafe portal or the SimCenter app, or it could even be a CLI or notebook application they are running on their own machine. So in general, we do need the authorize screen (and it is part of the OAuth spec).

With that said, we have discussed the possibility of adding an "approve always" option, so that a user only can essentially authorize a specific client app once for all time. That's a new feature in the app though and will take some coding to implement, but it is on the list.

[wesleyboar]

@joestubbs Your reply is very helpful. I think I get it now.[^1] It's similar to authorizing GitHub to connect to a client application, but multiple apps share the authorization. Since your response, Craig and I mocked up a proposed layout (below). Do you have any concerns with it?

[^1]: My scope of understanding of Tapis UI had been isolated to Core Portals usage, but now I see Tapis has features for clients with different authorization needs.

[joestubbs]

@wesleyboar the design looks beautiful! Thanks SO much

[wesleyboar]

New text was offered to internal stakeholders. (Internal reference.) PR #49 implements the text chosen by the majority.