Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

`OpenID Connect` (OIDC) is not `OpenID`, despite the confusingly similar name. For the most part, `OpenID Connect` prefers to the wall full of Sign-In Options buttons/logos for determining ID Provider, instead of a user entering some specific address (as `OpenID` used to) and a lookup process, because there is more ceremony involved in establishing trust between an ID Provider and Relying Party as OIDC is built on top of OAuth APIs and generally you need an OAuth token or API key for your application (Relying Party) to initiate the API calls to login (even if those API calls themselves are standardized and can share a lot of library code by `OpenID Connect`).

(You need a Facebook API key to enable "Sign in with Facebook" on your website, you need a Google API key to enable "Sign in with Google", and so forth.)

So users are just trained to look for "Sign in with Apple" buttons, and websites get encouraged to add "Sign in with Apple" to their wall of sign-in options. Apple is going to make it a requirement for large categories of iOS apps in near future, so that will probably bubble out into website adoption in general.



Yes, there is a way to do the dynamic functionality of OpenID 2.0 on Connect by using Metadata, WebFinger, and Dynamic Client Registration, but most of the large providers do not support all three of these.

Google (for instance) wants a relying party to do some amount of registration/click through first in a web browser before their site can rely on Google. Apple (for their part) hangs your ability to support Sign in with Apple off of an app registration, which requires a developer or enterprise account and thus an annual fee.


Yes, hence, "for the most part, prefers". Since it's an optional part of the spec and because basically no major OIDC IdP supports it nor plans to ever support it, it's basically nonexistent functionality.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: