New to WIP?
We're a group of makers shipping together. We help each other stay accountable and reach our goals.
Apply for access
Topics
Other questions
Back
Question
Unique usernames with multiple login methods?
How do you handle usernames when you allow users to authenticate with multiple OAuth options? When you have a single provider you don't need to worry much about duplicate usernames but if you have multiple providers then the usernames could overlap.
Normally this wouldn't be an issue if the name isn't used anywhere but if it's in a URL or something the user can share, what's the best solution you've seen for this?
Putting the service name in the URL so it's like {domain}/twitch/jaku, or allowing for something like Discord with {domain}/jaku#1337. Using a # in a URL will be its own set of problems as well. Maybe first come first serve, and if a duplicate name exists prompt the new user for a different name?
Has anyone run into this issue, or have other potential ideas/solutions?
Normally this wouldn't be an issue if the name isn't used anywhere but if it's in a URL or something the user can share, what's the best solution you've seen for this?
Putting the service name in the URL so it's like {domain}/twitch/jaku, or allowing for something like Discord with {domain}/jaku#1337. Using a # in a URL will be its own set of problems as well. Maybe first come first serve, and if a duplicate name exists prompt the new user for a different name?
Has anyone run into this issue, or have other potential ideas/solutions?
👋 Join WIP to participate
Hey Jaku, do you mean you create usernames once the user signs in based on the username from the oauth?
What I do in Mapmelon is creating the username from the email. I get the first letters plus add some random numbers.
Then I let the user update it if they want.
This way I make sure there will be no duplicates.
Go and give it a try here www.mapmelon.com/auth/signup
Yeah, so we would use the username of the account that is logging in with the OAuth provider that the user picked. The services we use already have a username for the user, which is where our problem basically comes in. Our users are content creators, so they may already have a following under these names, but we know there are some users that might be popular on Twitch with one name, and another user with the same name is popular on TikTok.
In our case, if two users were to log in to our platform and we used their names as an identifier in a URL, that would cause an issue when having them share a link like {domain}/{username} to their userbase.
I see you have Google and Facebook, and you ask for a name on signup but this works differently than what we are looking to do since the username is coming from the provider.
One issue I see with having the name getting set on a first come basis from one provider is that it can then create a domino effect of requiring users to find a new name on login. The first user comes in as Bob from Twitch, and the second user comes in as Bob from TikTok, we then ask TikTok Bob to change their name, so they change it to Tom. Now Tom from Twitch logs in and has to change their name, and even Tom from TikTok has to do the same.
I'm leaning towards a URL structure like {domain}/{service}/{name} so users can keep their names, and users trying to find their creator on our platform might be able to still guess another creator's URL if they already have an existing creator's URL. Just something about including the service in the URL comes across as tacky or weird I guess.
I'm not sure there really is any other solution that can meet my criteria, even if we went with the Discord route and the # didn't cause issues, users wouldn't easily be able to guess their creator's URL.
For what’s it’s worth I’m never a fan of this approach, as it temporarily exposes part of my email address to other users. Assuming the username is public.
How does it expose the email address? These names come from the creators' names on platforms like Twitch/Twitter/Discord. So twitch.tv/jaku my link would be mywebsiteservice.com/twitch/j….
I suppose if jaku is part of my email this is true, but they'd have to assume the rest of the email and what provider I'm using to receive email?
Unless I'm missing something here?
This was a reply to @reymon359 😅
Ah! That would do it. I see now, thanks for the clarification.
We ran into the same question with WIP where initially it was all based on Telegram usernames, but we then made having a Telegram account optional. Same with BetaList where we only used Twitter OAuth, but more recently added regular signups.
There isn’t a super clean solution.
What I ended up doing is letting the user choose their own username, but pre-fill it with their OAuth service name if available.
It hasn’t lead to any issues.
One extra benefit is that it gives people an incentive to sign up early to claim their desired username.
It's very possible I'm just thinking it will create issues of users with name overlap complaining that their names are not available.
The extra benefit of driving people to sign up early is actually a pretty nice incentive.
Thanks for the feedback.
I recently started working on a new system that will take in old accounts, new accounts setup both with SSO and Email, so came up with this pattern. All usernames are generated and used more as ID's in the system.
SSO (Using my service Hey.Café aka why called HC)
HC-SB3NX4L1E2
Email
EM-UTP3VW08H1
Legacy Imported Accounts
LE-SK7TTDVRHE
This way they never overlap but they are safe to share to the user, used for stuff like a user sharing an item to another. Plus it really helps down the road to integrate with anything as they are tokens that can be used anywhere as a token.