3

My registration system normally asks for 4 things: The user's full name, their email, their preferred username, and a password.

I want to add four oauth2 registration services to make it easier and faster for users to create an account.

I can see three methods for doing this, or maybe there is something more elegant I haven't figured out. Wondering what to pick. I am concerned about username collisions and ease-of-use:

Method 1

User clicks a button representing one of the four services. They confirm to allow authorization, and they are logged in. They get an email with their server-selected username, and somewhere in the interface that username shows as well.

In this scheme, the server will pick the username of the service if there's no username collision with my database. If there is a username collision, the server will add e.g. "2" to the username.

Method 2

With this method, they click to authorize, and then are prompted for the username either in the callback URL or in the original page, pre-populated with what the server thinks it should be. A little kludgy, but now they know what username they get, even if the email goes to spam.

Method 3

Two-step registration. The user (1) selects a username, and then (2) on the next screen they select either a full name / email / password, or to link it to a service via oauth2. Then (3) they authorize the link.

Observations:

  • Method 1 is simplest in general terms, but risks the user losing or never getting/seeing/confirming their username.
  • Method 2 is a bit kludgy.
  • I think Method 3 is pretty clean, but needs two steps to register. Regular registrations actually become longer now...
  • Method 3 requires a lock on a chosen username in the interim steps: If someone else creates a user with our user's username picked in step #1, and our user is in step #3, then the server needs to revert to Method #2 or Method #1. Alternatively, the username gets locked for some amount of time, but the edge case still remains. In summary, Method #3 is clean, but takes a few more steps than the other methods and has minute edge cases.

Thoughts on which method I should pick, if any?

  • 1
    If you are implementing OAuth, I don't see why you should ask the user for a username or password. It's unnecessary and annoying (from the UX standpoint). It's not like these users are going to provide you with 2 new credentials when they already made use of a 3rd party ones. – Laiv Jan 3 at 11:28
  • Method 3 is two-step. First it asks for a username. Then the username is "locked". Then, the account is created with that username via oauth or normal process. Users wouldn't get asked for a password if they went the oauth route. – Agamemnus Jan 9 at 1:53
1

It's really depends on your requirements of the system, and your load for choosing between method 1 and method 3.

I argue that method 1 in most cases will be frown upon by the users of your system, the user should have a choice regarding its' username created and it should be a uniform username across the services you provide (if not, why to register through you in the first place).

Method 2 will be hard to implement most likely, and it can creates many inconsistencies.

Method 3 really depends on the load of your system, the requirements of the users and tuning the username locking time. I believe that it'll be hard to maintain or scale later.

In summary, I suggest that you will:

  • offer the user a choice on its' finalized username

  • make this username uniform across the services.

If you have control over this four services it can be provided by registering in the same order, check for collision retract and ask the user for another username.

Else, it's probably infeasible and depending on how the user interact with the system - provide a consistent username from your service and save the map to the actual (maybe generated) username in your service.

  • I decided to use Method 2 actually. I try to use the third party's service for a hint on the username. If it's not available, I append "2" until it is. Then I send that as a suggestion in a callback. The person registering can then change their name (or not). Meanwhile, the second (final) screen lets the user accept the Terms of Service and Privacy Policy as well. – Agamemnus Jan 9 at 1:51
1

Do you mean single signon for the four services. For OAuth you should use something like Facebook or Google to authenticate the user and then you authorize the use any / all of the four services based on the roles of the user.

  • Yes, that's what it is, combined with a regular sign-in. But your comment should be a comment, not an answer, because it doesn't answer the question... – Agamemnus Jan 19 at 22:50
  • 1
    As I'm still a newbie when it comes to answering questions and didn't differentiate it. Will make a note of it to add it to comments section next time. Thanks for pointint it though. – Vasuki Ashok Jan 22 at 21:37

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.