WP-API / authentication

The home for design & development of a core WordPress REST API authentication solution
GNU General Public License v2.0
62 stars 2 forks source link

BuddyPress User Flow #3

Closed renatonascalves closed 1 year ago

renatonascalves commented 4 years ago

Bear in mind the user flow explained below is for a BuddyPress user, not a site owner or a developer.

Some thoughts

The user flow explained #1 is too complex and doesn't make sense for a community site. This is actually one of the problems of the https://github.com/WP-API/jwt-auth user flow.

And I already see people trying to, or actually, circuventing the normal workflow to allow for something I just described.

For example, I see apps creating a custom endpoint that receives the login/password information, authenticating the user, creating the token using jwt-auth or other auth plugin and returning the authenticated user/token.

Meaning, people are already bypassing the user flow that plugin author intended because the user flow is too complex for certain types of sites and community.

I presume something similar will happen with the user flow at #1.

**

Overall, I honestly agree with the security implications, but app creators, so far, are doing the easy way for their users, or trying to.

More thoughts

Having the user "connect with WordPress"

From a UX perspective, that doesn't make sense. Unless this is filterable.

User is prompted to enter their site's URL

From the users' perspective, that feels confusing. As a regular app user, I don't know what site url you are referring here.

User logs in and is redirected to a connected applications management screen showing "so-and-so application wishes to connect to your site."

As a user, I already provided my user login and password, so I don't need to confirm again what I just gave permission to.

This is the part I see people complaining the most. For a regular user, mostly non-tech, this process is dump, tiresome and complicated, regardless if there are security arguments for it.

--

Feedbacks to keep in mind when deciding this new user flow. :)

dshanske commented 4 years ago

The reason an authorization screen is necessary is that the site is being granted specific permissions. You should have the right to limit those. You can't limit scope after as you can't change a jwt token once issued.

renatonascalves commented 4 years ago

Totally agree @dshanske I'm not debating the technical or security decisions or implications. Only outlining user cases where people don't know or simply don't give a crap about those implications.

dshanske commented 4 years ago

I suppose that the question is what they experience on that screen, for the user flow question. I think everyone uses the same language because people are used to it. Maybe some future language brainstorming

aerych commented 4 years ago

Having the user "connect with WordPress"

From a UX perspective, that doesn't make sense. Unless this is filterable.

I'm thinking from the context of the WordPress apps. I agree, it would seem a tad strange to a user if the WordPress mobile apps presented a screen asking for you to confirm WordPress can connect to WordPress. Maybe its something we can manage with the right turn of phrase?

User is prompted to enter their site's URL

From the users' perspective, that feels confusing. As a regular app user, I don't know what site url you are referring here.

Maybe it depends on use case? For an app meant to work with any WordPress site (like the mobile apps) the first step would need to be identifying with which site to interact-hence asking for the URL. For apps that are dedicated to a specific site the URL would already be known and there would be no need to ask.

TimothyBJacobs commented 4 years ago

Having the user "connect with WordPress"

Yeah the language suggested is just suggested language that may or may not work for a particular app. This is all stuff that is within the app developer's control. WordPress isn't displaying this language.

The more important bit would be the flow of redirecting the user to a URL to login and approve the connection.

The part that WordPress is displaying is: "User logs in and is redirected to a connected applications management screen showing "so-and-so application wishes to connect to your site."

Maybe it depends on use case? For an app meant to work with any WordPress site (like the mobile apps) the first step would need to be identifying with which site to interact-hence asking for the URL.

Yep.

For apps that are dedicated to a specific site the URL would already be known and there would be no need to ask.

I'd also add here, that if you are building an app for a specific service that happens to use WordPress, a built-in auth solution isn't really necessary. It'd of course be great if there was something standardized, but if you are running the server the user is connecting to, you could have any flow you wanted, including just simple basic auth.