Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OAuth for the Open Web

aaronparecki.com

Post reply on HN
Print view View original

61–70 of 80 posts

Re: OAuth for the Open Web

#61

Post by icebraining »

user5994461 wrote: post #52
detaro wrote: post #51

Earlier quoted context omitted.

Right, seems I misunderstood it last time I looked at that spec or was misremembering, re-reading it one could of course point to an external service. Is there an actual implementation of that in the wild, that I e.g. could use with my e-mail address at my domain? Even support for discovery at all seemed basically non-existent.

It's already available if you use any of the major email provider. If you want to provide it from your own domain, it's perfectly doable, but it takes a lot of work to setup. This won't be usable from other sites though because they won't trust yoursite.com Discovery is non existent because it makes zero sense in practice.

This won't be usable from other sites though because they won't trust yoursite.com

Why do they have to trust it at all?

Re: OAuth for the Open Web

#62

Post by madspindel »

thomasfedb wrote: post #57
tiny-dancer wrote: post #41

Earlier quoted context omitted.

Keycloak is a personal fave for this general space https://github.com/keycloak/keycloak

Had a good look into this, also quite a complicated solution. I've been looking for a good solution to the "I have 3 small web apps that are used by the same people, I should centralise authentication and authorization" problem, and yet to find something sensible for that usecase.

Why not use Azure AD B2C or Firebase Authentication?

Re: OAuth for the Open Web

#63

Post by detaro »

user5994461 wrote: post #58
detaro wrote: post #53

Earlier quoted context omitted.

Ok, so you confirm that while the standards theoretically exist, OpenID Connect doesn't provide those features from OpenID in practice (where they did make sense for some reason?) You don't need trust to the domain if you just want "an identity" to recognize a user, which is the use case for many services: basically as soon as you allow e-mail + password sign-up, that's the only thing you get. OpenID did the same. De…

I don't understand your complaint. I suspect you have a fundamental misunderstanding of identity management in practice, irrelevant of whether it's implemented with OpenID, OpenID Connect or SAML. If you want people to register with anything, then just let them register with an arbitrary username and password. You don't even need an email or a domain.

I want what OpenID provided me: I give a site a URL to a page I control, and it goes there to figure out what service of my choosing to use to sign me in. I want this to be open, so I don't have to check with each site what whitelist of providers they accept.

I thus do not need to remember/manage a username/password pair per site, and am not tied to a specific service that might die, which was a big problem with the OpenID infrastructure dying bit by bit: those wo didn't use URLs they controlled to delegate lost their ability log in when the provider they used went away.

Re: OAuth for the Open Web

#64

Post by hardwaresofton »

user5994461 wrote: post #45
hardwaresofton wrote: post #30

Earlier quoted context omitted.

The battle between OAuth 1.0a, 2.0, and OIDC is really long and drawn out and doesn't seem to have a clear winner which I think is hurting everyone (though of course some companies are winning because they can support everything and offer that as value). I sure do wish people would just standardize on OIDC...

OpenID Connect is a subset of the OAuth 2.0 spec. They come in a bundle.

It's not a subset, it's a superset (or built upon Oauth 2.0 if that's the more accurate way to put it) -- I just read through the OpenID Core spec[0] today since I felt like I didn't know enough about it.

[0]: https://openid.net/specs/openid-connect-core-1_0.html

Re: OAuth for the Open Web

#65

Post by lstamour »

EGreg wrote: post #17
maxerickson wrote: post #14

Earlier quoted context omitted.

Browsers could implement that part of the UI. Like address autofill.

And until then what do we do?

The existing AccountChooser interface, which was Google’s preferred SSO strategy until their recent experiments with zero-click SSO, was hosted at AccountChooser.com by the OpenID folks.

Re: OAuth for the Open Web

#66

Post by lstamour »

daveid wrote: post #15
lstamour wrote: post #5

Great, it’s de-centralized OAuth. All we need now is a replacement for the hideous URL login prompt. My preference would be for an AccountChooser-style list of accounts you’ve recently used so you can pick one and sign in—and enter a URL (or email) only if you need to.

Unless there's gonna be native browser support, the different websites you visit won't be able to know which accounts you've recently used elsewhere.

Unless you centralize the list as AccountChooser.com does using Local Storage.

Re: OAuth for the Open Web

#67

Post by user5994461 »

jsiepkes wrote: post #60
user5994461 wrote: post #46

Earlier quoted context omitted.

The product is OpenAM from Forgerock, that is both open source and expensive. https://www.forgerock.com/ Gluu is just a facade company that's recompiling it from source and distributing the binaries for free. It supports pretty much everything you can dream of, including different password hashing and you can write your own plugins to interface with anything you like. However it's a very complicated product. It's for…

Gluu isn't based on OpenAM. Gluu is based on a whole bunch of other products (like Shibboleth) but not OpenAM. OpenAM originated from Sun's OpenSSO when Oracle bought Sun and FrogeRock was created. Incidentally this is the same time Gluu was created. OpenAM is also no longer opensource. The source was closed by Forgerock in the beginning of 2018. One of the forks that sprung from this source closing is wren:security…

Good to know. Gluu was built upon and dependent on ForgeRock products last I was working with it. I guess they're having a pretty bad time if ForgeRock pulled the sources.

Re: OAuth for the Open Web

#68

Post by user5994461 »

icebraining wrote: post #61
user5994461 wrote: post #52

Earlier quoted context omitted.

It's already available if you use any of the major email provider. If you want to provide it from your own domain, it's perfectly doable, but it takes a lot of work to setup. This won't be usable from other sites though because they won't trust yoursite.com Discovery is non existent because it makes zero sense in practice.

This won't be usable from other sites though because they won't trust yoursite.com Why do they have to trust it at all?

Because otherwise anyone could make an authentication provider that's authenticating as you@gmail.com and assume your identity.

Remember that the goal is to delegate authentication, user profile and/or user creation. It's implicitly trusting everything coming from the third party. For instance when supporting google login, it's expected that google only validate user accounts that really exist and are hosted by google.

Re: OAuth for the Open Web

#69

Post by mblaney »

EGreg wrote: post #17
maxerickson wrote: post #14

Earlier quoted context omitted.

Browsers could implement that part of the UI. Like address autofill.

And until then what do we do?

I made a bookmarklet that will store a url for you, and sign you in. You can create your own at: https://unicyclic.com/usb

Re: OAuth for the Open Web

#70

Post by dwaite »

dane-pgp wrote: post #25
daveid wrote: post #15

Earlier quoted context omitted.

Unless there's gonna be native browser support, the different websites you visit won't be able to know which accounts you've recently used elsewhere.

If browsers were to support this, there would be some tricky UI/UX questions about how readily the browser provides information to a new website about accounts you have on other sites. Such a feature might best be specified as an extension to this API: https://developer.mozilla.org/en-US/docs/Web/API/Credential_... which although experimental does have some level of browser support.

The web credential API is meant to be an integration point for passwords and AccountChooser in your browser. But I don't know if any other browsers than Chrome plan to implement it.
Post reply on HN