Apple Successfully Implements OpenID Connect with Sign in with Apple
openid.net
openid.net
https://bitbucket.org/openid/connect/src/default/How-Sign-in...
Since September 2019 all spec violations have been addressed by Apple, as recorded in the next section. The section thereafter - "Peculiarities" lists specific implementation choices by Apple that differ from what most implementations provide, but are not spec violations per se.
The previous HN discussion about the spec violations:
It's currently heavily focused towards The Netherlands, where citizens can obtain attributes such as name, home address and age. These attributes can then be selectively disclosed directly to a service provider, without the identity provider being able to see the transaction [3]. Multiple disclosures are also unlinkable as long as the attributes themselves are not identifying.
The fact that the identity provider is not at all involved with the transaction is an enormous privacy win compared to OpenID Connect, especially in the case of centralizing providers such as Apple – and less so in for example the domain of education single sign-on.
It's not currently using the verifiable claims data model, but it would very much fit it. It also doesn't use a 'blockchain', simply because it's not necessary to do so, and makes it all a lot less complicated.
[1] https://github.com/privacybydesign
[2] https://privacybydesign.foundation/publications/
[3] https://privacybydesign.foundation/meeting-slides/slides-8-3...
For a website to use IRMA, it looks like they have to stand up a server component on their web server - it’s not enough to simply include Javascript like browserid, but it also isn’t subject to the third-party cookie failure of browserid.
I find lots of cool shit on hn because people decide to share their side projects that I wouldn't otherwise have seen.
It only becomes a problem when people don't disclose they have a bias or connection to a product when they should.
[0] https://openid.net/specs/openid-connect-federation-1_0.html
Open ID Connect is essentially a an OAuth2 implementation. The original Open ID 1.0 concept, where you could use any identity provider with any service provider, is pretty much dead:
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.
Also FWIE, going to the permalink for a comment also gives you access to the flag feature.
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"))
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.
> 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.)
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.
(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.
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.
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 doubt it.
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.
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.
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.
It's limited in very fundamental ways, that will prevent many companies of any scale from using it. It's very difficult to make it work with an email service such as SendGrid, and it's limited to 10 domains you can prove ownership of, and 10 specific email addresses.
I work for a company that charges users and ships physical products – our payment providers and shipping providers all need to be able to contact our customers if they choose to use those services, but this would be essentially impossible (or a prohibitive amount of technical work at scale).
It's a very poor implementation. I wrote an obnoxiously long blog post about this. https://danpalmer.me/2019-07-02-on-signing-in-with-apple/
https://help.apple.com/developer-account/#/devf822fb8fc
In order to send email messages through the relay service to the users’ personal inboxes, you will need to register your outbound email domains. All registered domains must create Sender Policy Framework (SPF) DNS TXT records in order to transit Apple’s private mail relay. You can register up to 10 domains and communication emails.
It also seems that you could set up your own relay allowing those providers to contact your customers. In fact, that would be the privacy-conscious alternative even to your current implementation.
This data is shared for the legitimate interests of the customer. You've bought something and asked to a) pay for it, and b) have it delivered. I think it's reasonable to expect that the companies involved in this can contact you for the purposes of fulfilling your request.
This is all done under GDPR. The companies hold the data only for as long as they need, for the purposes explicitly requested by the user. This will all be included in privacy policies.
> It also seems that you could set up your own relay allowing those providers to contact your customers.
This might be technically possible, but introduces many concerns such as deliverability and spam ratings. Relaying email in this way is non-trivial when you're doing it at scale. For services sending ~100k emails a month or more, this requires careful planning because it's very easy to become filtered as spam.
2. 99.99% of all users probably want to be emailed tracking information or payment confirmation information. Adding such a checkbox only adds friction to their funnel in order to please an incredibly small minority of people using their site.
For credit cards, no it's not (but would be for pay-later, PayPal perhaps, Alipay, AmazonPay, maybe).
For shipping, most shipping companies have the option to handle the customer communication. When creating an order you provide them an email address and/or phone number, and they will send notifications. Many use these channels to provide the user the ability to reschedule deliveries, select delivery windows, change their delivery address, etc. This process is often also white-labelled so you may not realise that it's actually with the delivery company.
These details are not stored long term, only for the purposes of doing the delivery, any applicable returns process, and any insurance claims, etc.
It is possible to not do this, but assuming the retailer wishes to provide the same level of communication it means a much deeper level of integration, as tracking data needs to be ingested by the retailer. Given the industry has no standards for this, and "integrations" are SFTP + cron jobs once a day + CSVs, this can be pretty difficult, error prone, and result in a poor UX where you don't actually have the granularity of data to send an email when the package has been delivered.
> Friction and convenience used to be acceptable reasons to collect personal info without consent but maybe that’s starting to change.
We have found that it is within the user's expectation that we will share contact details to the third parties necessary to complete their order in this manner. It's in our privacy policy that we do this. We also check that all of our suppliers understand their GDPR responsibilities.
If it was done correctly, odds are good you wouldn't even know those emails originated from a third party vendor. Plenty off stuff you order is fulfilled by third party vendors who specialize in payment & logistics.
For example, if you ever ordered contact lenses from costco, the whole damn thing is driven from vendor called "WVA"[0]. I'm pretty sure it is completely turn-key. Only way I figured out what was going on was looking at the return address in streetview.
I ordered a lockpicking from an online vendor and it was fulfilled by some logistics provider on the east coast. Same kind of thing...
So I'm not actually sure what your problem is, but plenty of businesses have a need to share your contact information with their vendors.
I certainly don’t want anybody I buy from having my Apple ID email, and they should not assume that just because it is a user identifier, that does not mean it’s even used for email. Some retailers do this with things like paypal, and actually overwrite the supplied email address with the one from paypal. Really annoying.
The correct pattern is to ask the user for the email address that they would like you to have. And preferably, never send email to it again.
It is technically 10 DNS lookups and you can list as many IP addresses as you need on top of it.
Is Apple's policy is any different than this?
> How does the payments provider know if the customer has an outstanding balance? They use the customer’s email address.
> [...] Unfortunately this is completely ineffective for the pay-later scenario, which depends on being able to correlate user accounts.
I'm finding it hard that an organisation that is capable of doing a credit check on me (which doesn't rely on my email address) is unable to account for multiple debts without using my email address.
Infact, if they are only using my email address, that is absurd, as one email address != one person.
> Services that use dynamic domains (for example thread.foobar.com) will be unable to authenticate all of their domains.
Services that use dynamic domains (for example thread.youjustgotphished.com) will be unable to be authenticated by end users as being legitimate. Dont do it.
> Best practice for email deliverability suggests that senders should send from a different domain per category of email that they send8. This mostly applies to larger products, but 10 domains is too limiting.
Because our industry is rampant with spam, we have created new ways to try and bypass spam filters. Nope, go away.
> In the EU where GDPR restricts what companies may do with customer data, this leaves Apple’s SSO providing little to no benefit over what is already required by law.
Another layer of protection against companies that fail to abide by the law (and companies that wilfully neglect their obligations under the law) is more valuable than "little to no benefit" to end users.
Sorry to be really blunt, but these are just the highlights. As an end user, all I have for [the retailer] is a tiny violin. Retailers at large have demonstrated a fundamental lack of respect for end users. Apple's service looks like it lacks respect for the new-norms that retailers have adopted.
Good.
What we're talking about here is not spam. We're talking about transactional email that a user wants. I know that when we fail to send order dispatch emails users shout "Scam!" because it looks like we've taken their money without doing anything. I know that users like being able to pick up their order at a local store (with a security code). I know that users like to be able to pay with a range of payment options.
We're not talking about marketing here, we're talking about the minimum of communication for a user to feel that they can trust a retailer.
Yes the industry abuses email, but these examples are not that.
As for the credit check, email is certainly not the only signal they use, but in the typical case it's an easy one to check that can provide high signal. I don't want to speak for the service provider, but this sounds like one good approach to me.
> Apple's service looks like it lacks respect for the new-norms that retailers have adopted.
Apple's service makes it impossible for retailers who respect users privacy and marketing preferences to operate the core of their business.
> I get that you don't like spam. Neither do I! I'm very keen on anything to reduce this. What we're talking about here is not spam ... We're not talking about marketing here ... Yes the industry abuses email, but these examples are not that.
> Apple's service makes it impossible for retailers who respect users privacy and marketing preferences to operate the core of their business.
Unfortunately, while that may be true of your business, it's not true of others. You know the saying about bad apples spoiling barrels, right?
In the case of any legitimate email from third parties, your business can now be the relay for those emails. Instead of @ emailing me about a purchase from legitimateretailer.com, moving forward only *@legitimateretailer.com (and up to 9 more domains...) can email me about that purchase. And on top of that, legitimateretailer.com is required to do the bare minimum to try and reduce spoofing off their domain. Ideally DKIM and DMARC would be mandatory as well, and not just SPF!
For it to be any different, Apple would need to certify every partner in the chain used by any retailer. Every time a new partner is engaged, Apple would need to be notified and that partner certified. That seems even more onerous.
> As for the credit check, email is certainly not the only signal they use, but in the typical case it's an easy one to check that can provide high signal
KYC requirements in financial businesses are pretty strict. If losing this signal is a problem for your business, you're probably violating regulatory requirements. See previous remarks about value provided & legal requirements.
I wonder what their rationale is, for not doing that (given how easy it is, compared to all the other things they fixed).
But overall this is great news.
If an org supports social login, for instance, they are likely a consumer and a provider.
The user authenticates at an external OP (like Apple or Google), but a local account (or "identity") is always created by the service provider, which should be stored in an OpenID Provider.
> but it's ultimately an identity that Apple owns.
I would say that's slightly inaccurate.. it's ultimately identity information that Apple owns. And of course, Apple owns your account with Apple.
But the minute you "sign in with Apple" to any service, they too are creating a local identity for you (sans password). That identity begins with the information provided by Apple (e.g. name, email address, etc.), but can expand over time to include additional information provided by the user, not Apple.
Yes, some kind of recovery mechanism, some ability to set a local credential post-registration, or some ability to link and unlink external accounts, e.g. Sign in with Apple, then link your Google, FB, and Github accounts. Then, if you lose access to your Apple account, you still have additional options for authentication.
The latter two options are something I wish more organizations offered..!
> The scope value of only the very first request by an application is respected. If an application initially requests only the name scope, and the user allows it, it is then impossible to later also request the email scope.
So if you don't ask for the user's email right up front, you can never ask for it again later?!
You might later want: - to submit a support request and receive a response via email. - to get blog posts or product updates in your email. - to receive a transaction receipt
Trust is earned over time. I would much rather grant granular scopes as a product builds trust.
This way everything the app will need is up-front.
Great little "un-conference", hosted semi-annually in Mountain View, CA. Where a lot of the nuts and bolts were worked out for OpenID Connect.
In fact, today IIW 29 is coming to a close. Next gathering in April, 2020.
edit: from the comments it sounds like it has launched, but currently being implemented in a voluntary manner. Looked at the 9to5Mac article on iOS 13 support of apps and it looks like I just don't use any of them unfortunately.
Love the idea still and hoping it gains heavily in adoption.
[1]https://apps.apple.com/us/app/houzz-home-design-remodel/id39...
Edit: https://developer.apple.com/news/?id=09122019b
New Apps will be required to implement this immediately, existing apps have until April next year to support it before updates will be rejected.
It is available as part of iOS 13, yes but it will take time.
Wordpress is a good example of a service with a web implementation as well to try from the browser.
Harder to change everything later.
Classically, this is done merely by detecting that you've signed in on two different mechanisms using the same email address. That can still be done with Sign In With Apple for users that have opted to give the service their email address, but for users that opted to use Apple's email redirector, the service will simply need a way for the user to explicitly link it to another account (or to manually provide their email address).
This allows the site/user to avoid having to provide and store a password, since the site can just create an account and login the user based on the ID given by the provider.
Apple started using that protocol, allowing sites to authenticate users with them, but it broke a few parts of the standard, which meant the site developers couldn't use their normal libraries to connect to Apple's identity provider.
As a partial implementation, there were both difficulties using existing third party libraries and known security issues in Apple's implementation. This was shown initially by manual inspection, then by Apple's implementation failing the freely available certification test suite published by the OpenID Foundation (I believe run by third parties, not Apple themselves).
The OpenID Foundation published an open letter both to ask Apple to fix these issues, and to inform other operators that there were security issues with Apple's implementation.
A complete implementation solves known security and interoperability issues.
"Since September 2019 all spec violations have been addressed by Apple, as recorded in the next section. The section thereafter - "Peculiarities" lists specific implementation choices by Apple that differ from what most implementations provide, but are not spec violations per se."
[0] - https://bitbucket.org/openid/connect/src/default/How-Sign-in...
I can't wait till Apple fixes their account auto-lock feature. On weekly basis I have to unlock my account because someone is trying to login with my email. I contacted the customer service to see if something could be done to avoid auto-locking. The only suggestion was to pick another email address that's not common.
Also in order for me to unlock I have to supply my password along with answers to my 3 secret questions. Additionally my recovery email cannot be the same as my account email.
Why Apple's online is terrible compared to their hardware/software?
So here is a real story why I complained about requiring a different email address than the primary one. So a few years ago my apple account got locked due to their extra "protection". I tried to reset my password. I was given two options: to recovery by email or answer secret questions. Unfortunately I no longer had access to my works email and my answers weren't matching. It took another year till I could remember the exact answer I entered at the beginning. Till then my hundreds dollar of digital goods were locked out.