10 ms·
> And, with federated identity, you can also run your own, if you don’t trust Google or Facebook login. Sounds like OpenID...which was kind of a train wreck.
by curun1r 9y ago
> And, with federated identity, you can also run your own, if you don’t trust Google or Facebook login.
Sounds like OpenID...which was kind of a train wreck.
One middle ground could be tighter integration between browsers, sites and password managers. With the right specification, sites could offer a "register with [1Password,KeePass,LastPass,etc]" button which would open the password manager and pre-fill all the fields from a password manager's identity record (i.e. if a user has multiple identity records, the password manager can prompt for the one to use.) If there's a need to choose a username, there should be a standard endpoint for checking uniqueness. Once all information is filled out, the password manager can generate a password based on the site's specifications, post the information back to the site, store the account details and the site's ToS in its database and update the browser page to the success url. There can also be a standard endpoint for password rotation so the password manager can periodically update the password without the user's involvement.
This would still use passwords and for those that explicitly don't want to use a password manager, they could continue doing things the current way. But for the majority of us, it would be just like what you're talking about except that our identities would be stored locally in our password managers, giving us complete control over everything while automating as much as possible.
- deleted 9y ago[deleted]
- kuschku 9y agoThat’s another one of these half-assed solutions that the world has too many of, just like credit cards or using SSN as auth. No. We’ve solved all these issues before, OpenID was a good solution, and OpenID Connect – a complete rewrite – can be used to replace it, and is used already for Google and Facebook login. Just use OIDC, on every page, and allow users to choose an identity provider. Problem solved.
- StavrosK 9y agoI kind of agree, using OIDC with users selecting providers in the form of an email address (i.e. you enter an email address and the provider is selected based on that) seems like ideal UX.
- curun1r 9y ago> OpenID was a good solution Ugh...no. Just no. If you believe that, I'm not sure there's anything I can say that will get through to you...we're just going to have diametrically opposed opinions. But let me tell you that I've implemented it quite a few times on various sites and it's been a nightmare every time, so it's not like my 'half-assed' approach was ignorant of it being an option. It was based on specifically discarding that option as poorly conceived, poorly implemented and simply not being an option in many cases. Banks, for example, should never let a 3rd party IDP be part of their authentication process. And if your solution is inapplicable in situations where tight security is required, you've got to ask yourself whether you're actually solving the problem or just requiring users to be aware of two different ways of logging in instead of the one that they currently understand. Even if they do have to remember different passwords for most sites, most people can deal with username/password conceptually in a way that using a third-party IDP confuses them.
- kuschku 9y agoBanks should only allow auth via EMV chip and pin, like all German banks already allow. And for anyone else OIDC is more than good enough. Username and Password is in any situation less secure than OIDC.