While I do not agree with the premise of the quote, I don't find "customization" and "multi-device synch" tech-hipsterish - its exactly what happens with many phone app/webapp combinations.
They've since edited the article to say, "The primary use cases for requiring a login are providing security ,[sic] customization, multi-device sync and being able to reach out to the user."
I also see a login required on websites so they can monetize their customer base. For example pinterest or Houzz. Both websites should be able to operate without login.
In a multi-user system, authorization isn't a personal custom configuration. One way or another, it's a social problem involving multiple actors, and those actors have identity that the system needs to distinguish.
Everything in the article until the topic of "Multi-device support" is really just talking about how locally installed software has worked long before the Internet and SaaS.
If I buy and install a piece of software like Photoshop (pre-Adobe subscription Photoshop), I don't have to login to use it. It "remembers" my settings and customizations simply by storing them in a file on my computer. There's nothing stopping an app on my phone or tablet from doing the same.
When talking about "Multi-device support" we're really talking about device synchronization. You could consider a web browser/web app as a "device" for the purposes of this discussion. Since most devices can't do peer-to-peer synchronization, we often rely on the software vendor to provide centralized services. This requires identification and security which is typically implemented with username/password credentials.
> Multi-device support is when users are using your app on multiple devices...For most apps, this is really an over-rated feature.
Uhh, it's not? What happens when a user upgrades their phone? Or loses it? Since the OP has basically admitted they'll fall back on logins at some point, I think they're going to have a much harder time explaining to users that they need to add an email address later in the process (or worse, try to retrieve someone's data when it's too late). On the other hand, it is interesting to think that maybe there is a decent strategy here, where you gracefully migrate an app user without a login (high conversion) into identifiable user (lower conversion).
Agreed. What the poster doesn't seem to realize in the analysis on multiple device users is that the use case is not only about using multiple devices concurrently, but transferring from one device to another.
Agreed. I think it's important to keep in mind the context of your application when considering implementing a system like OP mentions. Although, it would interesting to provide the user a choice between a password/"secure" login and a device/"anonymous" login (with the option to later switch).
One caveat to the cookie-to-password switch: I am very good at saying, "Tomorrow." "Yeah, yeah, I'll do that tomorrow." Tomorrow comes and goes, I or a friend clear my history, whoops! Session lost.
At that point I am easily discouraged enough to stop using it.
E.g.: this happened to me with Khan Academy. I had watched so many videos on that cookie-only session, by the time it disappeared I'd long forgotten which ones I'd seen. Feeling a little discouraged, I thought, Okay, I'll get back to Khan tomorrow. Tomorrow never came.
If more people are like that, that could be a good reason not to allow cookie-only sessions for too long.
yes, definitely. for an app like ours, where its not mission critical or the user is not communicating and contributing with/to the community, anonymous works 90% of the time.
I was thinking this as well. I wonder, there must be statistics that show that annoying your users gets results, or they wouldn't be used so frequently.
I'm a big fan of the "email-only" login. Type your email address, hit login, switch to your email app, click the link, and you're logged in forever. If you don't have a password manager, it's probably what you do most of the time anyway via the forgotten password interface.
Except for when you click the 'refresh' button 20 times in your e-mail app and the e-mail still hasn't arrived. And then you check your spam folder, maybe it went there? Nope. And then for some reason, ten minutes later the e-mail shows up.
I don't know whether it's sites that add outgoing e-mails to a backed-up queue, or if it's an anti-spam heuristic somewhere adding the delay, or delay on the servers of your own webmail service, or whatever combination of these, but unfortunately it's certainly not always as simple as "switch to your email app, click the link".
I'm more a fan of how Persona does it, where you don't click a link at all, just enter your email and the Persona server checks a cookie secret you have to authenticate you.
Fundamentally the solution to all this is that you should have a signin at least once (to get your identifier keys securely) but then every website should authenticate against your keys, not against a username and password, and it should be transparent so as long as you are logged into an "account" you have personal keys for that identity that correspond to all the other services you use.
Really, its how the desktop works, and it is how the web should work, since they are converging and all.
Right, but an expiring, single-use link that will send a second email saying "someone from X place just logged in, so contact us if this wasn't you" is still good enough in most cases. To see that, ask which sites will send you a password reset mail when you forget your password. My bank certainly won't -- I have to talk to a person -- but most others do, making their passwords useless.
This is not necessarily through email. I was referring to the scenario where the the user has both screens open and is being shown the token on one and typing it on the other. I agree about the insecurity of email.
Email is just about the least-secure authentication path I can think of. Knowing what we know now, it shouldn't even be used for "forgot password," really. SMS, a phone call, heck even a Facebook message would be more secure.
No it doesn't. It has a standard username/password/forgotten email me setup.
What et1337 means is that you never even create a password, you literally login by putting just your email in, switching to your email, and clicking the link provided.
Given that most sites require you to do this when you first create an account to prove you own the email anyway, what was the point of having a password?
For cases when you want to trust this computer for logging you into X, but not into your email (compromised it lets anyone use anything that is yours), obviously.
So, in this scenario, losing the device (phone, tablet, computer) will mean losing access to the account right? It is coupled to device ID or some cookie right?
I am going to add an addendum about this which I will do now. On the app we are developing, the app installation has a unique id. Every once in a while, all of the "history" is stored in a secure fashion back on the server. So a device migration can be done. I must admit, losing a device is trickier because you wouldnt which id to use to restore on a new device. Let me think about this a bit
But seriously, this is literally the problem that logins were designed to solve. With a login, you are defining an external concept of "user" that is distinct from the device.
Available security factors are: something you are, something you possess, something you know. Right now, you're using something you possess (the device). The problem is, if I lose the device, I've lost my security credential, and no longer "own" my account.
To fix this, you could collect an email, and when installing your app, you could prompt the user if they want to use an existing account or create another. But then, you probably want to add some security in the form of a password... and then you've created a login.
> I must admit, losing a device is trickier because you wouldnt which id to use to restore on a new device.
This will happen. It will happen all the time. And when it does, people will be disappointed. People will stop using your app because they lost everything. I've seen this happen.
This system can work if the data is not important. But the nature of apps that store data or have a concept of "your data is stored" needs to account for cases where the original device is no longer accessible/usable.
> So a device migration can be done.
Relying on device migration is foolish. It will fail. And I will blame your app for losing my data.
We have this on JotForm. You can use JotForm fully without creating an account. I think it is important to give people freedom to roam your product freely before making a decision to create an account.
No, the primary use case for a login is when you need to actually authenticate to be authorized to access secure data.