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

51–60 of 80 posts

Re: OAuth for the Open Web

#51

Post by detaro »

user5994461 wrote: post #49
detaro wrote: post #44

Earlier quoted context omitted.

But not the extensions the GP cites as meaning OIDC solves the same problem. And even if they did, I don't think it allows to isolate your identity from the identity provider you currently use, which seems to be a key aspect of IndieAuth: You can delegate the role of Identity Provider to a third party, but can change that third party, similar to how you could in "original" OpenID.

Of course you can isolate the identity from the identify provider. It's fully supported by OIDC. It's a main use case for every website that wants to manage its user accounts.

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.

Re: OAuth for the Open Web

#52

Post by user5994461 »

detaro wrote: post #51
user5994461 wrote: post #49

Earlier quoted context omitted.

Of course you can isolate the identity from the identify provider. It's fully supported by OIDC. It's a main use case for every website that wants to manage its user accounts.

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.

Re: OAuth for the Open Web

#53

Post by detaro »

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.

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.

Delegation is helpful exactly because it is somewhat difficult to implement OAuth nicely. OpenID did the same.

Which I guess answers the original question of "why not OpenID Connect" with "because nobody in that ecosystem cares about those features, even if someone at some point wrote down how they can work".

Re: OAuth for the Open Web

#54

Post by floatboth »

user5994461 wrote: post #48
dane-pgp wrote: post #19

Earlier quoted context omitted.

> Why not OpenID Connect? Someone asked that in the comments of the article and the author responded with this link: https://indieweb.org/indieauth-vs-openid-connect The answer seems to boil down to IndieAuth being more decentralized.

Not at all. The answer is that the guy is pushing for his own product and company.

There is no company and product, there is a community and open specifications.

Re: OAuth for the Open Web

#55

Post by detaro »

user5994461 wrote: post #48
dane-pgp wrote: post #19

Earlier quoted context omitted.

> Why not OpenID Connect? Someone asked that in the comments of the article and the author responded with this link: https://indieweb.org/indieauth-vs-openid-connect The answer seems to boil down to IndieAuth being more decentralized.

Not at all. The answer is that the guy is pushing for his own product and company.

The author works for a company in the Auth space, but said company has no products based on this specification, and it was created prior to him working there.

Re: OAuth for the Open Web

#56

Post by xenophonf »

jtl999 wrote: post #37
xenophonf wrote: post #33

Earlier quoted context omitted.

Shibboleth is _the_ gold standard when it comes to SAML. I'm at the point where I don't recommend anything else, and I'm willing to help people deploy it (contact info in profile). For this use case, they'd also need to configure JAAS.

I'll give just Shibboleth a try later. I've been thinking of writing my own SAML IdP in Python (since I have plenty of experience with the language) and I'm not naive to the various security things that can go wrong, but I'm no expert cryptographer either.

I'll join the chorus recommending against inventing the wheel, unless you're doing that to learn SAML in which case I say more power to you. You should look into the existing work done by Roland Hedberg, SUNET, and others on pysaml2, which is now part of the IdentityPython project:

https://idpy.org/

https://github.com/IdentityPython

That said, I can't think of anyone using pysaml2 to implement identity providers aside from SATOSA, an IdP proxy. Nearly everyone I know runs either Shibboleth or SimpleSAMLphp. I recommend you run Shibboleth because there's a whole litany of interoperability issues you _won't_ encounter if you do. (The same goes for SimpleSAMLphp, but I have less experience with it.)

The IdentityPython and Shibboleth projects have a lot of overlap in terms of membership, and if you want to meet them and connect to the research and education side of the federated IdM community, which drives a lot of the open source work, you should come to the Internet2 Technology Exchange this year and stay for ACAMP. It's a super smart bunch of people. You'll learn a lot.

Re: OAuth for the Open Web

#57

Post by thomasfedb »

tiny-dancer wrote: post #41
jtl999 wrote: post #29

I was looking into SAML a while back for a project (preexisting compatibility) and the lack of functional open source IdP's is depressing. I tried Gluu and it's a RAM hog for what it does (IMO). I took a look at the developer docs and it seems all but impossible to override the password hashing method with your own (query passwords from your own database instead of LDAP hashed) was one use case I was looking into) Ev…

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.

Re: OAuth for the Open Web

#58

Post by user5994461 »

detaro wrote: post #53
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.

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.

Re: OAuth for the Open Web

#59

Post by floatboth »

jakubriedl wrote: post #26
daveid wrote: post #4

Earlier quoted context omitted.

OpenID doesn't provide API access like OAuth does, does it?

What do you mean by API access? OpenID Connect adds more features & standardization to OAuth2. So it supports everything that OAuth2 does. It all mentioned - user identity: core user info endpoint - discovery: https://openid.net/specs/openid-connect-discovery-1_0.html - client registration: https://openid.net/specs/openid-connect-registration-1_0.htm... And also other features which are important for more complex cas…

When people talk about just "OpenID", they usually mean the original one, not Connect. The old OpenID did not have the ability to authenticate requests to the domain you signed in with.

OpenID Connect adds lots of bloat, it's very large and complicated. IndieAuth is actually easy to understand and implement.

Re: OAuth for the Open Web

#60

Post by jsiepkes »

user5994461 wrote: post #46
jtl999 wrote: post #29

I was looking into SAML a while back for a project (preexisting compatibility) and the lack of functional open source IdP's is depressing. I tried Gluu and it's a RAM hog for what it does (IMO). I took a look at the developer docs and it seems all but impossible to override the password hashing method with your own (query passwords from your own database instead of LDAP hashed) was one use case I was looking into) Ev…

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 ( https://wrensecurity.org ). Disclosure: I work on that project ;-)

Post reply on HN