This content originally appeared on DEV Community and was authored by Arnaud Dagnelies
Isn't it quite silly that:
- every user has to register/login everywhere for any kind of website they use
- every developer has to implement the process of registering/login on their website
I don't know about you, but I'm annoyed in both cases.
OAuth2 got it backwards
Now, don't get me wrong, it's great that you can login with Google, GitHub or whatever... It's just:
- for users, it's annoying that you have to login/logout everywhere separately
- for developers, it's surprisingly complex to implement the OAuth flow(s)
The root of the issue is that OAuth2 is actually an "authorization" protocol. It was not meant to identify yourself. It's "dear provider, please allow me to use some parts of your API". Then, it's used solely to access the user's profile, in particular the email. This is provider specific, requires lots of know-how, app registrations, exchanging secrets, a backend to be secure...
What if...
When people are on a website, the login button redirects to "universal-login.xyz" (dummy) where the person can login. The main difference is that this information would be shared with any other website. No need for special auth flows, secrets or whatever. A simple HTTP request to /profile would give the profile, accessible to any website you visit.
But isn't it quite what XXX does?
You mean like Auth0, Okta, etc.? Well, not quite. These are more like OAuth2 providers "merging" many other providers. You still need the secrets and complex flows.
Advantages
- for users, you would just have to login once at "universal-login.xyz", and all websites using it would know it
- for developers, it would be so much easier! There is no flow to implement. Just a call to
/profileor a redirect to/login.
Drawbacks
It's not a perfect solution either.
- the flow has one more hop:
website.com <-> universal-login.xyz <-> gmail/github/... - any website you visit knows you are logged in, it's both a strength and a weakness
Technically
In order to make this possible, many things have to be properly configured. Login flows, CORS, SameSite, redirects... It is certainly not trivial, but I don't see any road block. Do you?
Lastly, identity has a lot to do with services. After all, you often need to know in the backend who the user is and need to thrust that information. Well, a call to /jwt could provide just that! A Json Web Token, a proof of your identity, only valid for your website.
Security concerns
Of course, security is paramount to such a sensitive topic. After all, it's about your online identity.
So, what bad things could happen?
- An evil website knows who I am!
- explicit consent should be required
- My website or server got hacked!
- luckily, the JWT can be constrained to the domain name, so that a stolen JWT cannot be used elsewhere.
- It is used to track me!
- they can already do that, independently from how authentication is performed.
If you see any vulnerability or undesirable behavior that I haven't thought of, please tell me!
... But most importantly, what do you think about it?
Would you use this "universal login" if it existed? As a user? As a developer?
Thanks for reading.
This content originally appeared on DEV Community and was authored by Arnaud Dagnelies
Arnaud Dagnelies | Sciencx (2022-01-19T08:07:15+00:00) Why no universal login?. Retrieved from https://www.scien.cx/2022/01/19/why-no-universal-login/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.