Seamless Create Account Onboarding Flow
jaxoncreed opened this issue · comments
Feature description
NOTE: I'm going to start building this now, so if you'd like, you can assign this to me, but any support or direction is helpful!
Use case:
- The user without a Pod goes to a solid app (https://coolchat.com in this example)
- The app tells the user to sign up for a Solid Pod and provides a list of Pod providers they could use along with a corresponding "Create Account" button for each pod provider.
- When a user clicks the "Create Account" button, a login flow is initiated and the user is redirected to the Pod's register page.
- The user creates a Pod and clicks submit
- The user is automatically redirected back to coolchat.com already logged in.
Currently, CSS only lets you open a /idp/register/ page. When you're done signing up, the user gets a "Thank you for creating an account page" and cannot be redirected back to the original application.
Implementing this use-case would make onboarding to Solid much easier.
I'm planning on achieving this flow with the prompt=create parameter as defined in the oidc prompt create spec
This probably should be built off this branch: #1677
there are also some discussions in: solid/solid-oidc#77
Currently, CSS only lets you open a
/idp/register/page. When you're done signing up, the user gets a "Thank you for creating an account page" and cannot be redirected back to the original application.
That depends actually. After registering, at the bottom of the result page there is a link to go back to the login page. So if you registered as part of an OIDC auth session, you can go back to the login page, log in with the new account, and then get redirected back to the application, which seems to sort of solve this problem already.
This probably should be built off this branch: #1677
Will do.
After registering, at the bottom of the result page there is a link to go back to the login page. So if you registered as part of an OIDC auth session, you can go back to the login page, log in with the new account, and then get redirected back to the application, which seems to sort of solve this problem already.
I'll build on top of the systems that already exist for that, but this doesn't solve the UX problem itself. We want to have as few steps for creating an account and logging in as possible.
One of the problems is that there is no standardized way of what "registering on a Solid server" means though. If you look at the branch with the new account management, there even isn't a single page any more that creates an account, creates a pod and links the WebID to the account. Now there is just a page that creates an account and attaches an email/password login to in, after which the user is redirected to an account page where they can create pods and/or link WebIDs. The idea is also that people can create their own HTML pages that make use of the backend JSON API that does the account requests if they want to have different support for account management. All of this would conflict with what is being suggested here I think.
Got it. I looked into the new account architecture and, as someome familiar with Solid, it all makes a lot of sense.
A bit of background for why I'm doing this: the current client I'm working with has a Solid app that's going to be used by a lot of elderly users, so an easy user experience is paramount. Asking then to register an account then log in again is too big of an ask for them. So, asking them to register an account, then make a Pod, then log in again is definitely too big of an ask. And I'd always want to lean towards the side of ease of use.
When you say "create their own HTML pages that make use of the backend JSON API," where do you imagine these HTML pages? For example, if I have a Solid app that wants to help people get a Solid Pod, do you imagine that app having a UI that takes a username, password etc and passes it to the JSON API? I don't think encouraging people to enter a password into an application other than the identity provider itself (even during the on-boarding process) is a good idea for two reasons: Firstly, password managers are bound to the domain name, so if you create an account on a domain other than the identity provider, that password will not be available when you eventually log in with the identity provider. Secondly, training users that it's okay to enter your password directly into services that are not the identity provider helps phishing attacks.
I'd like to build an alternative configuration that, by default, directs you to a register page that takes care of everything for you (creating an account, setting up a Pod, logging you in, then redirecting you back to the application), but there will be a small button on the page to direct you the more fine-tuned account management stuff.
As for the problem where there is no standardized way of what "registering on a Solid server" means, I agree that problem and there should probably be spec work to define that explicitly (though unfortunately I don't have the time to do this at the moment). But, using the oidc prompt create spec as a jumping off point seems apt. The problem with this spec is that when it says "create" it means create an OIDC account, not a webId. Though I could image a spec extension for Solid-OIDC that says "create" means "create" an OIDC account AND by whatever means (either through making a Pod and putting a WebId on it or using an existing WebId) provide a WebId.
When you say "create their own HTML pages that make use of the backend JSON API," where do you imagine these HTML pages?
I meant that a server being "CSS" does not define what is registration page would look like as people can customize their server to have different account-related pages.
I'd like to build an alternative configuration that, by default, directs you to a register page that takes care of everything for you (creating an account, setting up a Pod, logging you in, then redirecting you back to the application), but there will be a small button on the page to direct you the more fine-tuned account management stuff.
That's great, and what I meant with people being able to customize their CSS instance with the pages that they want. The problem is just that as long as there is no standardized requirement of what a Solid account registration should do, a client can not make assumptions about a server supporting this feature or not.
As for the problem where there is no standardized way of what "registering on a Solid server" means, I agree that problem and there should probably be spec work to define that explicitly (though unfortunately I don't have the time to do this at the moment).
You could use what you suggest here as a showcase to the spec of how it could be done and to show what would be required to be defined. Though I generally recommend features that are about advancing the spec to not be put into the main repository but be made as a separate component instead. Problem is that the new account management is still in a separate branch and this is not going to be released soon as I am still looking into improving how account data is stored and migration needs to be added. So perhaps for what you currently need a temporary fork of that branch might be the best solution?
If anyone interested, I've implemented this feature here: https://github.com/light-over/CommunitySolidServer/tree/feat/createLogin.
I'll close this issue as it's not going to be merged into main.