Over a million developers have joined DZone.

Sustainable Scenarios For Better Authentication

DZone's Guide to

Sustainable Scenarios For Better Authentication

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

In the first part of our post , we explained why user-defined passwords are not a sustainable mean for making the Web a safer place for private matters or business. So what? As there’s no going back in the use of the Internet – on the opposite, whole sectors of our activity continue to shift online – authentication needs to be fixed in some reliable, standard, future-proofed way. Here are some thoughts on realistic paths to take – and some dead-ends to skip.

Killing some myths

Online authentication has drawn a huge number of entrepreneurs in the past 15+ years, and has been the field of countless initiatives. Ever heard about Passport? OpenID? OAUTH (in its initial goals)? InfoCard? IDeNum…  Most have failed, not to say all have failed – We hope to be contradicted, but having spent more than 5 years in this industry myself, we've witnessed a lot more complete failures than half-successes. The only one we can think about that had a true impact is Facebook Connect. Why is that?

There are a lot of reasons, such as: assuming that users would pay or buy something, or assuming that security is something that users care about… We won’t expand on these long-lasting myths: just don’t build a start-up on these assumptions. But there is one single reason why – with the very few exception(s) mentioned – no single system has yet succeeded to replace passwords for user authentication: the gap between one-sided and two-sided markets.

Top-down is the key word for two-sided markets

Let’s explain this. With passwords, sites don’t have to make any assumption regarding users: you’re asked to create a password, and that’s it. But if a site wants a better authentication, or wants that you don’t have to create a new password, you have to bring something else instead (a certificate, a token, an account with a login service…). That “something else” operates on a two-sided market, on one side the sites supporting it, on the other side the users having it. The big concern with two-sided markets is not price, it’s adoption: sites waiting that enough users have it to support it, users waiting that enough sites support it to care about it and possibly then get it.

How do you get past such a situation if you’ve invented an authentication solution that you’d like the world to use? Well, sadly you don’t. Subsidize the accepting sites? You can’t subsidize the paying party of your business model in order to build it! And, as said, you’d have to pay them more than what you’d expect them to pay you, because the problem with your system is not the price. So this is a complete dead-end (cf. SwissID). Be the first one in the right ecosystem? Yes, it worked for Paypal within the eBay ecosystem, which turned out to be a large enough user base to enable Paypal to convert millions of sites. And this is the reason why it worked too for Facebook Connect; not that they were really the first ones, but they started with a 500M+ user base: which site can resist it? Top-down is the key word for two-sided markets where users don’t pay: it’s just recognizing the fact that an enrolled user base turns a two-sided into a one-sided market.

Social login isn’t the end of the story

Social login (e.g. Facebook Connect or sign in with Google+) is great for social applications – especially mobile Apps. Discovering my network saves time and brings value. That’s the reason why it has got such a huge traction in the last 2/3 years, with hundreds of thousands of sites accepting Facebook Connect (see e.g. these stats).

But that’s not the end of the story. This method for signing up exposes my entire network to applications, which I usually prefer to avoid unless this is the very purpose of the application – and so do my connections. It offers a quite low sign-in security to accepting sites, because it’s still user-defined passwords that won’t probably be unique. And sites that don’t need my social graph have no convincing reason to support social login, so I will still be left with a ton of identities to manage.

Facebook Connect and a few others have won the battle for signing up to social applications. But what about online authentication? We mean authentication for banking, payment, healthcare, gaming, public services, and for the myriad of sites where signing in with your favorite social network doesn’t make any sense?

User-centric and site-centric identity: the future is hybrid!

Let’s consider authentication needs from a site perspective; the market can be roughly segmented in sites that

  • need social login
  • need a higher login security or prefer to outsource user credentials management, whatever the reason (real money, reputation, privacy…)
  • want to shorten their sign up process
  • don’t care

In order of appearance, authentication for these segments would look like as follows:

  • social login
  • some form of 2-factor / 2-step authentication, if affordable / securely implemented (see our previous article on this topic)
  • social login or a privacy-respectful equivalent, based on something users are already enrolled in (e.g. “sign in with email” initiative by Mozilla Foundation, which entirely observes the top-down constraint that I stressed)
  • login & passwords; realistically, sites where you need to create a password will not disappear overnight. Passwords are there to stay

Well… From a user perspective, this hybrid and segmented authentication future looks even darker than the current, not so bright, situation: maybe not more passwords, but many more ways to authenticate! Are these the sustainable scenarios I teased you with? Where will the rescue come from?

Augmented Personal Clouds

The concept of Personal Cloud is emerging: it’s about giving users a way to choose who their Identity Providers are, that is, who is authenticating them when they sign in to a site. With social login, the Identity Provider must be your social network; with a Personal Cloud, it can be anyone you choose – even yourself if you run an authentication server, this is quite similar to the ‘old’ OpenID model. One of the differences is that this is compatible with a “sign in with email” approach, because it implements a discovery protocol similar to DNS, where your email address can be the entry criteria; with OpenID 2.0, if you wanted to sign in with your email address, your Identity Provider had to be your email provider. Not with Personal Clouds.

What does it change? It’s similar to social login, you wouldn’t need to create a new password with sites accepting such a model, because you would be authenticated by your Personal Cloud Provider.

What are the chances that this model succeeds better than the previous ones? Personal Clouds don’t face the two-sided market problem, among others because they are compatible with a “sign-in with email” approach. They are therefore more likely to flourish. Some organizations, like Respect Network, which inWebo joined this year, are developing a framework and a business model around Personal Clouds.

Can this help defragment authentication? Yes. Sites delegating their authentication will contribute to this objective. But let’s now remind that a Personal Cloud is a service. What if a Personal Cloud Provider was at the same time a secure authentication provider for site-issued identities? And a secure Cloud-based password manager?  Let’s call it an augmented Personal Cloud. Such a service reconciles the various types of authentication from a user perspective. And none of the components faces two-sided markets issues.

Science fiction? Well, we’ll open the doors this year, stay tuned.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}