NoAuth – Easy Authentication with Privacy

[konsalexee]

I have a question that I am unable to answer to my self the last days.

Any help and thoughts would help for sure. I am curious why nobody provides an authentication service that would work with OAuth 2.0/OpenID with privacy on it's centre. Let me explain my self further.

It would be lovely if there was a service where I could make an account, verify that I am a real human and then I could use them to login to various apps or platforms.

I would love to see a substitute of Facebook/Google login with data privacy in the centre. And for data to be safe and not distributed for advertising reasons, this service would need money to survive. So I would pay for that kind of a service.

Have anyone thought or worked on anything like this? Why it is not feasible so far? Any thoughts?

ProtonMail someone would say can be a way of implementing this, if we sign in with our ProtonMail email. So then, why they do not create an OAuth 2.0/OpenID services to let their users signup anywhere they want with ease?

[sr7201]

I thought about throwing something like this online, as I have my own openID provider that could sort of do this. Napkin thoughts:

Privacy isn't actually an easy one on this one. This provider would need to provide a way to "remember" you well enough to allow you to recover parts of your account (any of the credentials, basically). To do this, you do need to store a modicum of data about the user. Ideally: - Email address or other form of contact - Challenge-response (to prove you didn't just magically gain access to the email address) This alone provides huge problems if your goal is privacy, at least when managing the relationship between users of your service and you. You will need to store some of that data, and you need to guarantee that it is safe.

On the link between you and the third-party applications, things get both easier and more complicated at the same time. The OpenID spec specifies that an id_token needs to contain the following, based on scope: - email: email, email_verified - profile: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at In order to provide the privacy you're describing, there needs to be a way for a user, when going through the authentication flow, to allow, deny or spoof the data. Most websites requesting openID will not let you through the gates if you deny one of their scopes, for instance, so the service needs to be able to handle the spoofing part.

The data also needs to be impossible to cross-reference if a parameter is spoofed. Quick thoughts on that: - The email spoofing must be unique per application ID - The field spoofing must be unpredictable enough - All fields of the id_token that can uniquely identify the user must be unique per app, to prevent cross-referencing. The token<->profile lookup must be able to understand this

On the whole, with careful thought about the scope of this, it might actually be pretty straightforward.

[konsalexee → sr7201]

> The OpenID spec specifies that an id_token needs to contain the following, based on scope: - email: email, email_verified - profile: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at

I understand the need of an email and other data, and that they can work as PKs in the Web/Mob apps' databases. But also those data are a medium to communicate with the actual user.

So again I am curious about why ProtonMail doesn't provide a mechanism like this. They have all the data, the brand and the credibility to run a service with the following business model.

[elchapucho]

I believe this can quite easily be done. The only issue I can see is adoption.

Websites are not gonna spend time and money on adding authentication by an other third party if this authentication system/service is not accessible by a huge amount of users. Like you said, most of the time what you can see is auth with Facebook and/or Google. That is because a huge amount of internet users have an account on one or both of those platforms and that makes it worth the money to add them to some website's auth system.

On the user's side, some users will agree to pay for a privacy focused auth system but that will still be very few users. This can be an attractive solution for a subset of the internet users who are more privacy aware. But, some users will want services to use the auth solution before they create an account.

It's a bit like an egg and chicken dilemma.

[konsalexee → elchapucho]

> I believe this can quite easily be done. The only issue I can see is adoption.

I believe the adoption will be from tech-oriented platform let's say for example Codepen, Brave and other if you can demonstrate the value proposition to the devs which are developing currently concerns about privacy. Privacy Invasion is real.

> But, some users will want services to use the auth solution before they create an account.

This is true and in order to kickstart this, an OSS community could help a lot.