I'd have preferred improvements to OAuth, see: https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45... and https://vimeo.com/52882780
OAuth for the Open Web
21–30 of 80 posts
Re: OAuth for the Open Web
#22Why not OpenID Connect? Not only does it have discovery for OAuth2 endpoints, it also specifies how to discovery the OIDC endpoint from a bare domain and username via WebFinger. It also has extensions for dynamic client registration, supports flows that work with input-restricted clients, as well as single page apps, and the UserInfo endpoint. And it's also already implemented and supported in lots of places. There a…
> 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.
Aha, one more bit of indirection ala OpenID v1 to make the base identity portable. I like it. Thanks for the link!
Re: OAuth for the Open Web
#23Great, 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.
You mention "URL (or email)", so I think it is worth pointing out that there is a standardized way of converting an email address into an HTTP URL, namely WebFinger.
The RFC even includes an example of doing something very similar to this use case:
Re: OAuth for the Open Web
#24If URLs are to be used for user IDs, it'd make sense to require TLS, so we can remove the scheme from the IDs, so it's more memorable.
Also the mockups are really confusing, you're logging in with a URL, not a "domain". Also, having the example text as "you.domain.com" would confuse users who have "github.com/user", as used in the previous examples.
Re: OAuth for the Open Web
#25Great, 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.
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.
Re: OAuth for the Open Web
#26I don't understand why the need for this new protocol; what's missing from OpenID?
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 cases than just simple "login using X" button.
Re: OAuth for the Open Web
#27This 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" button.
Re: OAuth for the Open Web
#28OAuth 1.0a includes authentication and authorization. OAuth 2.0 is designed for authorization only and could be vulnerable to account takeover/impersonation attacks. MasterCard uses OAuth 1.0a instead of 2.0
https://developer.mastercard.com/blog/why-mastercard-doesnt-...
Re: OAuth for the Open Web
#29I 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)
Even storing my custom hashes in LDAP would have been acceptable.
Re: OAuth for the Open Web
#30This 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…
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...