Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More clarity on OAuth sign in page #3169

Open
TylerFisher opened this issue Dec 3, 2024 · 2 comments
Open

More clarity on OAuth sign in page #3169

TylerFisher opened this issue Dec 3, 2024 · 2 comments

Comments

@TylerFisher
Copy link

Is your feature request related to a problem? Please describe.

I've implemented the new OAuth process on sill.social, which is mostly working great. However, I get a number of confused users who are unfamiliar with the new process and are hesitant to use their main password because they think I'm trying to steal it.

Describe the solution you'd like

I think there are a number of ways to address this, some of which are better explanations on my end. However, one I'd love the Bluesky team to address is to add some more clarity about what is happening on the PDS OAuth login screen.

Screenshot 2024-12-03 at 9 42 02 AM

Currently, there is nothing on this page that indicates that you are authenticating with your PDS and that this is a secure method for login. This leads people to think this is not a legitimate login form.

Describe alternatives you've considered

Currently, I try to explain this up front on Sill. It certainly helps, but I still get questions.

Screenshot 2024-12-03 at 10 15 04 AM
@KevinCathcart
Copy link

The issue here is that more than just Bluesky can use a PDS, and users of a PDS may not even use Bluesky at all. This means specific references to Bluesky on the generic PDS login page would be inappropriate. Using the full Bluesky theming for a PDS not hosted by Bluesky would be even worse, as it would wrongly imply the host is affiliated with the public benefit corporation.

It is entirely reasonable for for the Bluesky hosted PDSes to use Bluesky branding because they are the hosting provider, and obviously in that scenario the user will be a Bluesky user. Unfortunately, the OAuth screens are not currently designed to be sufficiently theme-able to accomplish that without editing the source, and I think the Bluesky team wants to avoid maintaining a Bluesky themed fork of the OAuth code.

Generic ATmosphere branding would be appropriate for self-hosted PDSes, and might be usable for the Bluesky hosted PDSes too, but unfortunately I'm not sure there is good logos and branding guidance for the greater ATmosphere and to the extent that there is, I'm not sure users would recognize that branding.

@matthieusieben
Copy link
Contributor

matthieusieben commented Dec 10, 2024

You are 100% right. We should really help users understand what's going on. Thing is, OAuth is still in its early phase. Our UI/UX engineers didn't work on that interface yet. But be assured that this is something that will be improved in the future.

Meanwhile, thank you for doing your part in educating users.

Regarding the branding per say, self hosted PDS are not using the official colors & logo. Nor should they (they can customize the colors and logo to whatever they want). They do are using the same code, which means that the interface is similar to the official one. This is something that was foreseen and is actually a desired behavior (users should expect an "Atproto user experience" when they login using their atproto credentials)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants