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

71–80 of 80 posts

Re: OAuth for the Open Web

#71

Post by dwaite »

detaro wrote: post #63
user5994461 wrote: post #58

Earlier quoted context omitted.

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…

But in practice, OpenID 1/2 were a nightmare.

Most of the implementations were incomplete/broken, everyone wanted to provide OpenID while nobody wanted to consume it, and the few parties that did consume it got left holding the bag when the OPs ripped out support and left users without a way to prove their identity to recover their accounts.

You want at least a weak unilateral arrangement, such as Google or Microsoft or Facebook saying they have no plans to rip the feature out from under you any time soon.

Also, OpenID adoption was never going to happen with users being identified by URLs. No party was going to step up and explain to users why they should go through the effort of learning all this tech to use it vs. using the passwords they were already familiar with.

Re: OAuth for the Open Web

#72

Post by dwaite »

detaro wrote: post #43
jakubriedl wrote: post #27

This seems to me as just a subset what OpenID Connect is. OIDC is an addition to OAuth2 and supports 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 cases than just simple "login using X" butto…

Does anything actually implement discovery? I looked at various OpenID Connect implementations a while back and nobody seemed to support it. It's a pretty big user-education problem if you can't just say "you can use OpenID Connect", but have to explain "you can use OpenID Connect, provided your provider supports Extensions X and Y, and they probably don't clearly document that they do, so please just try logging in…

Quite a few things implement discovery. Most IDPs advertise metadata, and many RP libraries consume it by default. IDPs even motivate them to consume it by rotating signing keys pretty often.

Not many things support dynamic client registration, which means the list of IDPs a site can use are pretty static.

Re: OAuth for the Open Web

#73

Post by dwaite »

floatboth wrote: post #59
jakubriedl wrote: post #26

Earlier quoted context omitted.

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.

Depends on your point of view. IndieAuth has a bunch of modifications to OAuth2 behaviors that may not be compatible with existing deployments, and requires software to implement things like full HTML parsing libraries to read out link tags. There were many incomplete OpenID 1/2 implementations, and compatibility greatly suffered as a result.

As someone who maintained an OpenID 1/2 OP for a few years, I would much rather implement OpenID Connect Basic Profile than IndieAuth.

IndieAuth, like OpenID 1/2, also assumes the user has a known profile page or even knows what a URL is, which are both statistically unlikely.

Re: OAuth for the Open Web

#74

Post by icebraining »

user5994461 wrote: post #68
icebraining wrote: post #61

Earlier quoted context omitted.

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 googl…

Well, no, it would only accept IDs of the format *@yoursite.com for the provider yoursite.com (or the provider yoursite.com has delegated to).

Re: OAuth for the Open Web

#75

Post by user5994461 »

icebraining wrote: post #74
user5994461 wrote: post #68

Earlier quoted context omitted.

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 googl…

Well, no, it would only accept IDs of the format *@yoursite.com for the provider yoursite.com (or the provider yoursite.com has delegated to).

Authentication cannot be bound to any email or format.

For instance when using google authentication, the user and the email can be anything, because google apps support custom domains for paying customers.

If you want to rely on emails, just use emails.

Re: OAuth for the Open Web

#76

Post by willow9886 »

user5994461 wrote: post #67
jsiepkes wrote: post #60

Earlier quoted context omitted.

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.

The Gluu Server bundles a fork of OpenDJ 3.0 for persistence, the last open source build. It also supports OpenLDAP, and will soon support Couchbase.

Re: OAuth for the Open Web

#77

Post by willow9886 »

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 a cloud provider like Google Identity, Okta, OneLogin, etc?

Re: OAuth for the Open Web

#78

Post by willow9886 »

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 writes its own software, like the OAuth2 Authorization Server, oxAuth, and bundles other open source software like the Shibboleth SAML IDP.

Re: OAuth for the Open Web

#79

Post by icebraining »

user5994461 wrote: post #75
icebraining wrote: post #74

Earlier quoted context omitted.

Well, no, it would only accept IDs of the format *@yoursite.com for the provider yoursite.com (or the provider yoursite.com has delegated to).

Authentication cannot be bound to any email or format. For instance when using google authentication, the user and the email can be anything, because google apps support custom domains for paying customers. If you want to rely on emails, just use emails.

For instance when using google authentication, the user and the email can be anything, because google apps support custom domains for paying customers.

That's what delegation is for.

Re: OAuth for the Open Web

#80

Post by xenophonf »

user5994461 wrote: post #47
jtl999 wrote: post #37

Earlier quoted context omitted.

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.

Not to be dismissive but better look for an alternative solution. The SAML spec is a beast, you can work on it for months, you will hardly get a few percents of it working. If you're doing that for a small company, maybe try to get a Microsoft active directory instead. It's a lot easier to setup and maintain and everything does their best to integrate with it.

I realize it's a little late to say this, but AD FS is garbage. I've run AD FS both as an InCommon IdP and an InCommon SP, with both as full federation partners. While I solved the metadata consumption, attribute scope checking, and discovery UX issues, I encountered lots of little interoperability issues that required disabling request/assertion encryption or switching between SHA-1/SHA-256 on individual CP/RP trusts. Ultimately, we replaced the IdPs with Shibboleth and moved the SPs behind SATOSA, which works a LOT better.
Post reply on HN