You are unique. You are yourself. Why should you register / login separately to any goddamn website out there?

Let's imagine a different internet. What if... you go to any website and it knows it's you. Or a little safer, by giving it the permission to know it's you.

From a developer's perspective, you could simply send a GET https://universal-login-site/profile to get the user's profile. If either the person is not logged in or the person has not given consent to you to read its profile, you would obtain a 401 - Unauthorized and a simple redirect to https://universal-login-site/auth would suffice. This page would perform the registration/login/authorization and once done go back to the original website. There, a call to https://universal-login-site/profile would now work as expected.

Note that this is independent on "how" the login itself is performed. It might be a traditional email/password, a comfortable redirect to google/microsoft/apple or even some fancy authentication with biometrics. In the end, the result is the same, you can access the user's profile.

Now, there are some services out there like Okta and others which provide you a login screen which does exactly that, don't they? Well, not exactly. The core difference is that you have to setup things specifically for your website: you require an account, exchanging client IDs, secret IDs, reading docs and so forth.

Here, we are talking about a "public" login service. Where once logged in, it would apply to all websites/services using it.

So what would be the benefits of such a "public/universal/shared" login?

1. the user does not have to register separate accounts
2. it reduces the risk of having hacked accounts
3. developers have trivial implementations
4. users might be already "known" at their first visit
5. users can fine-tune their security settings across the board

Actually, point (1) and (2) is what "social login" is about. People prefer login using google, microsoft, apple, etc. since it is both more comfortable and safer.

...but it leaves the developer with (3): the pain point of interfacing with those, and for anyone having already experienced it, it is far from trivial! Actually, it is very challenging to do it right.

And wouldn't it be nice if (4) you could spare your users from registering at all? Well, that would be possible with such a public login. If the user already has an account and your website is trusted, BAM! The user's profile is already available at the first visit!

This reverses the role of who decides the security policies. The user has now the power to (5) to choose whether it prefers simple login, two factor or biometrics, to authorize every thrusted site automatically, or require permission first, make its sessions long lived or short lived... It's now in the user's hands.

Simple right? Heck yeah! ... Less friction, more security, and way easier to implement.

But hey ...wait ...there is something missing here! What about the server side?! The backend needs a proof that you are you! You cannot just send "I'm Joe" to the server and expect it to trust it blindly. Well, you could also deliver the profile as "json web token", which is a signed proof of the user's authenticity, for your website only as audience.

So, what do you think of that? If there was such a "public login" service, would you want to make use of it as a web developer?