You can allow people with apple accounts to login into your website without to write Apple specific code. Just use whatever lib you've been using to allow people to auth with their Google accounts or any other 3rd party openid connect idp

What value would they enter at what prompt in order to activate the Apple Accounts process? For example, "openid.apple.com" or "some_email_address@openid.apple.com" or ...?

Usually you offer a connect button with the most popular providers. You could also detect a login with somename@whateverapplemaildomain in order to passthrough for those addresses. There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds.

In the end, probably would just add an apple-logo button next to twitter, google and facebook auth buttons.

----

Aside, in terms of data storage, separate the account, user and login/auth details. An account is related to activity inside the system. A user is a person authorized to use/act on or as that account. A login is an authority and related information to enter as a given user. Logins can be an OpenID reference, AD Integrated User, an API token, a local password entry (salted/hashed of course).

If you make the separations above, you'll have far fewer issues if/when you need to make your application more flexible in terms of users/authentication against accounts. It also is very helpful when you will have "individual" accounts and "business entity" accounts, which may have variances in UI/UX.

Beyond this, would separate the actual API/UI systems from auth systems relying on integrated tokens (like RSA signed JWT on an internal authority). In this way, your API systems only need to worry about "allowed" signers, and the roles assigned in the token's claims. Of course then there are issues with token lifetime, refresh and revocation to consider.

Sorry for the blathering on this, literally working on an authentication management system (fairly barebones initially) right now. MVP at end of day after 4 months work.

> There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds.

I'm aware of OIDC's webfinger discovery mechanism; IIRC, it lets you translate "person@example.com" into a valid login. (But I don't think I've ever seen anyone implement this.) Is there something else?

I think you could also implement just a DNS identifier to OIDC discovery which would let you translate something like "apple.com" into an OIDC flow, but you would need the provider to publish a OIDC discovery document, which Apple's implementation does not do. (Why, IDK, since that seems like a really easy thing to do. But Google — which does have one, technically — also isn't "google.com" or "gmail.com", so entering this seems a bit hard for a user to enter. (It's under "accounts.google.com"))

My Apple ID is a personal email address at a custom domain name. I also use the same email address as a Microsoft ID. How would/should/could a service be expected to take my email and determine what services it is associated with? I assume that’s not really possible, and as an end-user I don’t particularly want that to be possible anyway.

But let’s take a simpler scenario, just because my email address is something@gmail.com, does that mean Google should be used as the OAuth provider? Maybe I use that same email address as an Apple ID and as a Microsoft ID as well.

There’s a lot of confusing edge cases with OIDC.

If I understand correctly AppleID is supposed to obfuscate your real email such that the website you connect to will only see a hhfyguihry636357484@privacy.apple.com or something similar.

optionally, IIRC

I'm mostly trying to clarify if the parent poster knew about something more than Webfinger, since his post mentions "DNS/http(s) services"; wasn't sure if that referred to Webfinger, or something else.

> How would/should/could a service be expected to take my email and determine what services it is associated with?

By following the OIDC standard, namely, using Webfinger discovery. I was mostly confused since, AFAIK, OIDC only mentions webfinger, not DNS, so I was curious if the parent to my post knew something I did not.

> as an end-user I don’t particularly want that to be possible anyway

I don't see why not. Note that this is discovering who the identity provider associated with an email is in an automated way — this is not discovering what services you log in to with that identity. That is, for "example@gmail.com", Webfinger would discover that Google is the identity provider. This is something a human can — roughly — already discern from the email anyways; this just provides an automated means. Moreover, it provides a means for the service wanting to log you in to then subsequently redirect you to; there are certain configuration parameters needed beyond just the email.

The idea is to make it simple for the average user: just enter your email.

> just because my email address is something@gmail.com, does that mean Google should be used as the OAuth provider?

Not necessarily, but I think the OIDC flow there is pretty good. One could imagine an implementation whereby GMail allowed you to specify an alternative IdP for your email, and then responded to with that when queried. This is more to do with Google's implementation. (Which, AFAIK, doesn't implement Webfinger at all, so it is kind of moot. And while I doubt they'd ever implement this sort of thing, the point is more that an IdP under your control could / that nothing in the spec prohibits it.)

> Maybe I use that same email address as an Apple ID and as a Microsoft ID as well.

I think OIDC supports this. The Webfinger query is not limited to a single result. (Though, given the paucity of webfinger implementations, I don't know how well UIs would handle this. But again, implementation vs. specification.) Even if that didn't work, you could always enter your IdP hostname directly into the RP, and it could either Webfinger that, or just see if that hostname is the IdP by attempting to pull the metadata from it.

(It is sad that most OIDC implementing RPs only give you a few hand-selected buttons leading to major IdPs to choose from.)

Microsoft's online login is probably the most prominent example of translating "user@domain.com" into a SSO login/redirect that uses Azure AD or another SSO provider for signon that I can think of.

I know it's based on DNS and/or HTTP(S) entries for the common SSO, just don't recall all the specs off hand.

For the google/apple and other very common cases you can detect by a whitelist for the domain part. For others, if there isn't a discovery mechanism in place, would have to defer to internal (password) created accounts.

It's a bit of a mess, fortunately there's a handful of TLDs that account for over 95% of public users. IIRC, when I worked at emailage, it was something like >85% of requests were from 20 domains, and 95% or so were from 100.

I wish there was an easy way to save a hackernews comment for later

Click on the 'X minutes ago' permalink on the comment, and then select 'favorite'. It will show up under 'favorited ... comments' linked from your profile page while logged in.

More generally, and as hinted to by floatingatoll, the the 'X minutes ago' is also a permalink meaning after you click on it you can bookmark it in any bokmarking system you use. (I use pinboard.in)

Also FWIE, going to the permalink for a comment also gives you access to the flag feature.

Oh! Very nice! Thank you!

Favorites also works on stories (which you may already know).

`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.

Huh? Maybe you mean @icloud.com or @me.com. There is also a discovery/query mechanism that should tell you if x email is registered on a specific idp but I don't think Apple implemented it. Anyway there are various UI/UX solutions. Check gigya and related openID SaaS providers.

It is usually button "Sign in with...". In your app, each identity provider has to be configured (and your app has to be enrolled with the identity provider). Similar, as with Google, Github, etc.

> So I don't currently use Apple products, does this mean that people can use their own OpenID Connect identity providers with Apple ... or is this just for using Apple's Identity Provider to allow your own apps to log-in via your Apple account?

The latter - like other IDPs that support OIDC, an website can now use Apple for authentication with the same libraries as they use for Google, Microsoft, etc.

> Open ID Connect is essentially a an OAuth2 implementation.

OpenID Connect is an OAuth2 profile.

> The original Open ID 1.0 concept, where you could use any identity provider with any service provider, is pretty much dead.

The functionality is there, but is optional. As a result, it is seldomly used.

OpenID 1.0 supported using arbitrary OPs, but there was no actual organizational trust there:

- if the OP and RP had an interoperability issue, the first time it would be seen would be with an end-user. In many cases, the only way the OP/RP would know there was an issue would be when the end-user reported it. - if the OP messed up authentication and let the wrong person in, the RP had no recourse. - if the OP went away, you could very well have no alternative mechanism to recover the user account on the RP side - neither side necessarily took responsibility for the user education of how a URL ("what is a Earl?") could be used for authentication

Even in its heyday, there were 10x more OpenID 2.0 OPs than RPs because of these challenges. In my opinion, it was more that the very concept was not ready for the market. That is why with OpenID Connect, most parties have not deployed this sort of user-centric Bring-your-own-OP approach even though it is a capability of the profile.

OpenID Connect’s most frustrating aspect is its naming, reminding me of a time when OpenID (1.0) was more commonplace.

With OpenID Connect, users only get the benefit if the site implements a particular identity provider... a continued move to the walled-gardenism of the net.

Except that TCP/IP, email, and the web has shown that it can also be otherwise. Big sites come and go. I don’t think you can always state general rules along these lines (cities are different from hosting source code). You have to look at the friction vs advantages per scenario. The web, for example, has little friction due to Google providing the grease, and massive long-tail advantages in decentralization. OpenID has a lot of friction in its implementation, and few known identity providers exist for most individuals... not to mention trade offs in the implementation and profile details available per provider create incentive for developers to only put a “sign in with Facebook/google” button on their sites/apps.

On the last point... in general, a lot of sites, in order to let users participate only really care about having a name and email address or phone for contact needs. Most don't really even care about that. Why not let any number of other systems take care of that. For that matter, they also handle validation.

I'd rather let FB/Google/Twitter and now Apple deal with verification details, and let them participate in a site. It also means, on doesn't have to deal with persisting or dealing with passwords (that can be breached) etc.

Of course, I'm still inclined to allow local/passworded accounts and ensure salt+hashing of passphrases, etc. It's just in a lot of ways much easier as a user.

Depending on the site, I'd often prefer Twitter (until my short account ban/lock, which made life more difficult for a few days... FYI, don't rile up the communists too much).

I wonder if people "centralize", i.e. gather, around cities to enjoy the more and varied (decentralized, even?) opportunities afforded. Many rural areas force centralization of, say, one grocery store or one hardware store. There is generally one town center, whereas in larger metropolitan areas one can choose from many, many different social circles, markets, and to some extent even governmental centers. That strikes me as a big win for decentralization.

Even your example of git seems counter to your point— can you imagine if all version control ground to a halt whenever GitHub went down?

I realize this is off-topic, but it is an interesting thought.

> why 99% of git usage is on Github, Gitlab or Bitbucket

I doubt it.

There are a lot of corporate or "free" projects that are on self-hosted platforms; plus, there are a number of other players with smaller but non-negligible share such as SourceForge.

Its a mix, fully centralized takes power away from people and sucks. Fully decentralized is not stable enough to survive as something useful. The trick is finding the right balance between. Generally its safe to bias towards decentralization because so much historically has overly tended towards centralization.