So I am creating a user registration system with oauth login to four services. How do I handle username selection?

Question

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?

Answer 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.

Answer 2

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.