
NoAuth – Easy Authentication with Privacy - konsalexee
I have a question that I am unable to answer to my self the last days.<p>Any help and thoughts would help for sure. I am curious why nobody provides an authentication service that would work with OAuth 2.0&#x2F;OpenID with privacy on it&#x27;s centre. Let me explain my self further.<p>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.<p>I would love to see a substitute of Facebook&#x2F;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.<p>Have anyone thought or worked on anything like this? Why it is not feasible so far? Any thoughts?<p>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&#x2F;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
> 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
> 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.

