
Apple Successfully Implements OpenID Connect with Sign in with Apple - atestu
https://openid.net/2019/09/30/apple-successfully-implements-openid-connect-with-sign-in-with-apple/
======
floatingatoll
The working document linked to by this press release:

[https://bitbucket.org/openid/connect/src/default/How-Sign-
in...](https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-
Apple-differs-from-OpenID-Connect.md)

 _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:

[https://news.ycombinator.com/item?id=20311000](https://news.ycombinator.com/item?id=20311000)

~~~
jchw
And in fairness to Apple, most OIDC implementations have peculiarities. The Go
OAuth library has a handful of quirks for specific providers.

------
Confiks
Shameless plug (but I hope that's okay, again): IRMA Authentication is an
open-source app [1] and protocol that offers privacy-friendly attribute based
authentication and signing using Camenisch and Lysyanskaya's Idemix [2].

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](https://github.com/privacybydesign)

[2]
[https://privacybydesign.foundation/publications/](https://privacybydesign.foundation/publications/)

[3] [https://privacybydesign.foundation/meeting-
slides/slides-8-3...](https://privacybydesign.foundation/meeting-
slides/slides-8-3-19/ringers-8-maart-2019.pdf#page=2&zoom=auto,-68,540)

~~~
preommr
> Shameless plug (but I hope that's okay, again)

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.

~~~
yread
I wouldn't call it a side project - it's supported by the government and city
of Nijmegen but very cool

------
djsumdog
So I don't currently use Apple products, does this mean that people can use
their own OpenID Connect identity providers with Apple (like if I run an Open
ID Connect server at idp.example.com, I can add it as an authentication
source) or is this just for using Apple's Identity Provider to allow your own
apps to log-in via your Apple account?

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:

[https://battlepenguin.com/tech/the-decline-of-
openid/](https://battlepenguin.com/tech/the-decline-of-openid/)

~~~
sdegutis
Decentralization always fails, centralization is inherent to society and human
nature. That's why we generally centralize around areas that turn into huge
metropolitan cities, and why 99% of git usage is on Github, Gitlab or
Bitbucket. We're a centralization-loving race. So OAuth 1.0's dream of
decentralization resulted in only a few OAuth providers ever lasting long.

~~~
azinman2
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.

~~~
tracker1
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).

------
nathancahill
This is really great. So many people were up in arms about Apple releasing an
implementation that didn't comply with OpenID. Good on Apple for addressing
the issues.

------
danpalmer
I'm glad they've got the tech right for the actual authentication, but their
email relay is still far from usable.

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://danpalmer.me/2019-07-02-on-signing-in-with-apple/)

~~~
IfOnlyYouKnew
I've rarely seen vendors sharing e-mails with payment and shipping companies,
and would consider it somewhat icky for privacy reasons, especially when done
without the user's consent.

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.

~~~
danpalmer
Many delivery providers need to be able to contact the person they are
delivering to. This is standard practice. The same is true for many non-
trivial payment providers (such as PayPal/Klarna).

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.

~~~
ryandrake
What stops the user from consensually providing this information in a form
field at checkout, if they wish for such contact?

~~~
spookthesunset
1\. You already gave those downstream vendors your contact information so they
can, you know, ship your package to your home and charge your credit card.

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.

~~~
ryandrake
Thanks for that . A couple of things: 1. I don’t think an E-mail address is
really necessary in order to ship a package or charge a credit card. 2.
Friction and convenience used to be acceptable reasons to collect personal
info without consent but maybe that’s starting to change. I highly doubt the
99.99% figure but having no data of my own I won’t dispute it. I trust that
you have seen such an opt-in rate for sharing E-mail addresses in your past
user research.

~~~
danpalmer
> I don’t think an E-mail address is really necessary in order to ship a
> package or charge a credit card.

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.

------
atonse
I wish Apple would actually publish the configuration document too (under the
well-known URL, as listed in the peculiarities). It makes it one less step for
OpenID clients to follow.

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.

------
yoz-y
This is maybe the first time I see a positive open letter. Kudos to both
parties.

------
madrox
Slightly off topic, but it's been frustrating to me that large organizations
only want to implement OpenID providers and not consumers. What Apple has done
makes it easier to bring your Apple identity across the internet, but it's
ultimately an identity that Apple owns.

~~~
willow9886
Basically, if you're a large org, you _must_ be an OpenID Provider (OP).
Optionally, you might _also_ be a consumer.

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.

~~~
madrox
You are correct in that quite often who implements provider vs consumer
depends largely on market position. There is technically no reason Apple can't
become a consumer, other than they aren't interested in doing so. Also
consider that, should Apple choose to eliminate your account, then you've lost
whatever you use Apple to sign in with unless those downstream providers offer
some kind of recovery mechanism.

~~~
willow9886
> Also consider that, should Apple choose to eliminate your account, then
> you've lost whatever you use Apple to sign in with unless those downstream
> providers offer some kind of recovery mechanism.

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

------
dfabulich
Looks like Apple fixed all of the critical issues here
[https://bitbucket.org/openid/connect/src/default/How-Sign-
in...](https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-
Apple-differs-from-OpenID-Connect.md) but left in some "peculiarities," some
of which are _quite_ unpleasant.

> _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?!

~~~
orangepanda
How is that a bad thing?

~~~
scient
How is it not? Consent to releasing information should be supported on a
granular on-demand level. If I initially only need name, I'll ask the user to
consent for that. If I later on need an email (lets say for some additional
functionality user is trying to access), I'll ask for email separately. This
is much better than being constrained to only the initial scope being
respected, resulting everyone basically request everything right away, faced
with a situation where they can't do it later.

~~~
floatingatoll
Can you offer a real-world example of when this would be the case for a
product where logging in is required?

~~~
freehunter
Even from a user standpoint... oops I clicked the "cancel" button when I meant
to click "confirm" and now I have to go through the signup process all over
again because the developer is not allowed to ask me again.

~~~
yreg
Last time I touched permissions the app was able to give the user a link to
iOS Settings page where the user can grant previously denied permissions.

------
heyoni
So they actually responded by fixing those issues? I wonder if they went as
far delaying the release for that. If that’s the case, +1 to Apple for privacy

------
willow9886
For those of you interested in this topic, check out Internet Identity
Workshop:
[https://internetidentityworkshop.com/](https://internetidentityworkshop.com/)

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.

------
wil421
Thankfully. I do not use sign in with Google or Facebook and I would not feel
comfortable signing in with any Ad company’s credentials.

------
jsgo
has sign in with Apple launched yet? It was the Big Thing in iOS 13 that I was
personally most excited about but honestly, if it has launched, I haven't seen
it yet.

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.

~~~
Gaelan
Apple was planning on making SIWA support mandatory, but pushed that back to
2020.

~~~
ogre_codes
For new Apps it is mandatory, existing apps have until April of next year to
support it before updates will start getting rejected.

~~~
Operyl
Only mandatory if you use Facebook/google sign in.

~~~
dwaite
Any third party sign-in.

~~~
Operyl
Yeah, sorry, was over generalizing it. They did make that first-party
exclusion for SSO thankfully.

------
baby
Can someone explain who is OpenID, what's the OpenID Connect Self
Certification Test Suite, and why it is so important that Apple follows their
spec?

~~~
dwaite
OpenID Connect is a profile of OAuth 2 that adds authentication and identity
information. Sign in with Apple was a partial implementation of OpenID
Connect, for sharing authentication as well as an email address and the user's
name between Apple and other apps/services.

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.

------
shujito
sorry for this but this page is messing with the mouse scrolling, how can I
prevent that? I've seen other several pages that do the same

------
paul7986
Say I have a web service with users but don't offer an email service with my
core offering. Im guessing by using this I wouldn't be able to build iCloud
Mail into my main service; allow my users to view, receive and send iCloud
Mail through my web service?

------
sroussey
Still not to spec. And no PKCE? Oy.

~~~
evanriley
But it is to spec. [0]

"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...](https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-
Apple-differs-from-OpenID-Connect.md)

~~~
topspin
That list of "peculiarities" is pretty disappointing. The lack of a discovery
endpoint is sad; it isn't that difficult to provide and it _greatly_ reduces
the obscurity of configuring RPs.

------
antimora
Apple's online credential/auth* user experience is terrible.

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?

~~~
pojzon
To be honest I read all your complaints as a "screw Apple for protecting me"..
pretty disrespectful. Their answer is expected. If your email is something
like "john.smith@gmail.com" \- there are like few hundred thousends of Smiths
there.. And the complaint that recovery email cannot be the same as account
email - so you want your account to be compromised without ANY way to recover
it? Those seem like complaints of a completely "security oblivious" customer.

~~~
antimora
I am talking about the basic user experience for my iTunes music, video and
apps. Apple's "protection" of my account isn't better or stronger than other
popular online services, such as, Facebook, Dropbox, or Gmail. I have more
sensitive data in my Dropbox and Gmail accounts than Apple's. And yet I go
through trouble each week to unlock my account. Why do I need to be troubled
by it to get access to things I paid for?

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.

