3 ms·

I... would like to sign up but I can't because I don't want to use Facebook, Google or Twitter. Can I just give you my email and you send the login token per em

by lucb1e 7y ago

I... would like to sign up but I can't because I don't want to use Facebook, Google or Twitter. Can I just give you my email and you send the login token per email instead of through a third party?

1hakr 7y ago
When I made login, I just wanted to keep it simple as it all mostly data.
- lucb1e 7y ago
  What is mostly data? You mean the site is mostly static content and you wanted to keep it all the same level of simplicity? I've found making websites where one can create a username and password to be way simpler than implementing design-by-committee systems, so I don't really understand why that wasn't the obvious choice.
  - minblaster 7y ago
    It’s simpler to create a db, password, keep up with correct salted hash scheme, email password reset, mail service, getting through spam filters, user profile icon? As soon as you’re dealing with customer info you took on a bunch of requirements.
zamadatix 7y ago
I'm sure it's crappy for the 1% of normal users that don't want to login through one of these services but really who wants to manage a first party user system, the fake accounts, the security breach risks, and updating that system just for 1% more users on a 60k/y project. Bigger fish to fry.
- lucb1e 7y ago
  Please change my mind: I don't see the difference between keeping access tokens and keeping a password (in technical terms). You also mention fake accounts: I don't know what this site does (I wanted to filter on a field and it told me I needed to login for that, not sure how a fake account would help me defraud the owner using that) but I would hope that random website owners can't tell Google/Twitter/Facebook about how naughty I've been and get me banned from Google/Twitter/Facebook. Therefore, the site owner will still have to ban spammers that created a Google account, same as they have to ban spammers that created an email address. Every time I've tried to implement a third party login, it has been quite a pain. "First party user system" is a fancy word for what is actually the simplest option. At least to me, as a developer, so I don't see the advantage from that perspective either.
  - bg0 7y ago
    Password reset logic is the big difference. A lot easier just to use a third party token authentication service than to code all that logic. Wouldn't it be just as easy for you to create a new google account and use that to sign in? I totally get it from your point of view, but whenever I make passion projects - if I don't have to build user management features in terms of passwords - it's a big load off my plate.
  - zamadatix 7y ago
    The 3rd parties have went out of their way (via incentive) to make this the easiest possible option. Access tokens "just happen" from a process perspective. There is no need to create a password reset system, a "forgot username" system, a 2 factor auth, password policy, or enforcing password resets in certain scenarios. Tokens shift all of that work to the 3rd party the user already does this with and allows your app to simply integrate and be done, to never have to think about these things again. If the user wants to use TOTP, SMS, a second email, or interdimensional VR dance greeting in 10 years you don't need to worry about it, the 3rd party does. "Therefore, the site owner will still have to ban spammers that created a Google account, same as they have to ban spammers that created an email address." Sure, but instead of trying to be better than Facebook/Twitter/Google at making it hard to create spam/fraud accounts you simply have to block the ones that get through the already best systems in the world. You don't need to track IPs, fingerprint patterns, phone numbers, emails, etc to try to filter out automated systems the 3rd party does it for you and is always getting better with 0 effort on your part. It's also frees you from ever needing to ask for more information than needed. Don't need their phone number? Great, you'll never leak it because you don't need to request it from the 3rd party or user or account when requesting the token. Just have a token instead of a password? Great, if the user practiced poor password security Google/Facebook/Twitter are more likely to block suspicious logins than you ever were AND you don't have to reset their password and send them an email, the 3rd party will. Also tokens auto expire/renew as part of the app logic, down to minutes if you want, all without bothering the user. If you've tried to implement 3rd party logins as additional steps to your already first party system you don't really gain any of these benefits . If it's all you implement it can save quite a bit of work. In the end though nobody should be changing your mind, it's you that should explain why the developers should support a 1st party only system and turn away those that don't want to create yet another web account or why they should support both and the associated burden for the 1% that won't login via 3rd party.
- wolco 7y ago
  1% it is much higher than you realize. 30% on the low enn and upto 85% on the highend.

by lucb1e 7y ago

I... would like to sign up but I can't because I don't want to use Facebook, Google or Twitter. Can I just give you my email and you send the login token per email instead of through a third party?

1hakr 7y ago

When I made login, I just wanted to keep it simple as it all mostly data.

lucb1e 7y ago
What is mostly data? You mean the site is mostly static content and you wanted to keep it all the same level of simplicity? I've found making websites where one can create a username and password to be way simpler than implementing design-by-committee systems, so I don't really understand why that wasn't the obvious choice.
- minblaster 7y ago
  It’s simpler to create a db, password, keep up with correct salted hash scheme, email password reset, mail service, getting through spam filters, user profile icon? As soon as you’re dealing with customer info you took on a bunch of requirements.

zamadatix 7y ago

I'm sure it's crappy for the 1% of normal users that don't want to login through one of these services but really who wants to manage a first party user system, the fake accounts, the security breach risks, and updating that system just for 1% more users on a 60k/y project. Bigger fish to fry.

lucb1e 7y ago
Please change my mind: I don't see the difference between keeping access tokens and keeping a password (in technical terms). You also mention fake accounts: I don't know what this site does (I wanted to filter on a field and it told me I needed to login for that, not sure how a fake account would help me defraud the owner using that) but I would hope that random website owners can't tell Google/Twitter/Facebook about how naughty I've been and get me banned from Google/Twitter/Facebook. Therefore, the site owner will still have to ban spammers that created a Google account, same as they have to ban spammers that created an email address. Every time I've tried to implement a third party login, it has been quite a pain. "First party user system" is a fancy word for what is actually the simplest option. At least to me, as a developer, so I don't see the advantage from that perspective either.
- bg0 7y ago
  Password reset logic is the big difference. A lot easier just to use a third party token authentication service than to code all that logic. Wouldn't it be just as easy for you to create a new google account and use that to sign in? I totally get it from your point of view, but whenever I make passion projects - if I don't have to build user management features in terms of passwords - it's a big load off my plate.
- zamadatix 7y ago
  The 3rd parties have went out of their way (via incentive) to make this the easiest possible option. Access tokens "just happen" from a process perspective. There is no need to create a password reset system, a "forgot username" system, a 2 factor auth, password policy, or enforcing password resets in certain scenarios. Tokens shift all of that work to the 3rd party the user already does this with and allows your app to simply integrate and be done, to never have to think about these things again. If the user wants to use TOTP, SMS, a second email, or interdimensional VR dance greeting in 10 years you don't need to worry about it, the 3rd party does. "Therefore, the site owner will still have to ban spammers that created a Google account, same as they have to ban spammers that created an email address." Sure, but instead of trying to be better than Facebook/Twitter/Google at making it hard to create spam/fraud accounts you simply have to block the ones that get through the already best systems in the world. You don't need to track IPs, fingerprint patterns, phone numbers, emails, etc to try to filter out automated systems the 3rd party does it for you and is always getting better with 0 effort on your part. It's also frees you from ever needing to ask for more information than needed. Don't need their phone number? Great, you'll never leak it because you don't need to request it from the 3rd party or user or account when requesting the token. Just have a token instead of a password? Great, if the user practiced poor password security Google/Facebook/Twitter are more likely to block suspicious logins than you ever were AND you don't have to reset their password and send them an email, the 3rd party will. Also tokens auto expire/renew as part of the app logic, down to minutes if you want, all without bothering the user. If you've tried to implement 3rd party logins as additional steps to your already first party system you don't really gain any of these benefits . If it's all you implement it can save quite a bit of work. In the end though nobody should be changing your mind, it's you that should explain why the developers should support a 1st party only system and turn away those that don't want to create yet another web account or why they should support both and the associated burden for the 1% that won't login via 3rd party.
wolco 7y ago
1% it is much higher than you realize. 30% on the low enn and upto 85% on the highend.