
Open Letter from the OpenID Foundation to Apple Regarding Sign in with Apple - julian37
https://openid.net/2019/06/27/open-letter-from-the-openid-foundation-to-apple-regarding-sign-in-with-apple/
======
motohagiography
Between lack of a a nonce and an asserted exposure to code injection and
replay attacks, the issues in the letter imply a week of vulnerability
research could yield a complete takedown of the product - which would suck
because an Apple sign-in experience using their TEE is really valuable.

I could see someone making the choice where they would elect not to manage a
nonce because its permuting effect was achieved by other parts of the
protocol. Apple also has keys in a TEE, and a nonce generated and synchronized
outside of that could have been interpreted as creating additional attack
surface.

If the OpenID letter is correct, there are exploitable vulnerabilities in
Apples implementation that could be demonstrated. If they are not correct,
they could just be angry Apple is leveraging its TEE to assert it doesn't need
governance from this standards body because the standard is written for
products without a separate hardware keystore.

~~~
empath75
I don’t think they said there’s a lack of a nonce, it seems to be saying that
they’re not allowing the client to set the nonce.

~~~
phs318u
If the second part of your sentence is true, could “allowing the client to set
the nonce” be considered an increase in the possible attack surface?

~~~
TJSomething
The entire point of the nonce is that it can't be predicted by anyone but the
client, proving that the client initiated the transaction. This is done by
having the client send it over TLS and having the identity provider sign the
nonce as cryptographic proof.

Also, by my reading, the problem is that the standard requires the nonce
parameter to do something and Apple ignores it.

~~~
johnjonesyc
exactly, this looks like the protocol has been intentionally weakened to
provide on the wire access. (state actors / telco)

The excuse that they dont want to sign up to the Terms and Conditions holds no
water

If they are serious about security adopt OpenID in full (they dont have to
join just pass the tests) and put fido2 security key functionality on every
Apple device

Apple have made some smart moves but now the marketing dept need to do the
right thing for security standards.

------
blue_devil
This might answer some questions:
[https://openid.net/connect/faq/](https://openid.net/connect/faq/)

Also

>Are there live production deployments of OpenID Connect? Yes. Some examples
include Google, Gakunin (Japanese Universities Network), Microsoft, Ping
Identity, Nikkei Newspaper, Tokyu Corporation, mixi, Yahoo! Japan and
Softbank. There are also mature deployments underway by Working Group
participant organizations, such as Deutsche Telecom, AOL, and Salesforce.

For an example of OpenID Connect at work, look at Google+ Sign-In, Google’s
flagship social-identity offering, which is entirely based on OpenID Connect.

~~~
jrockway
Is OpenID Connect the one where it issues a JWT that you can then verify and
exchange for a session cookie? If so, I love the API. Very easy to use, and
easy to integrate multiple sources.

~~~
user5994461
Short answer is yes but long answer is no. OpenID Connect doesn't define
anything about the token format or the use of cookies. It's really more of an
authentication framework, that leaves a lot to the implementation. Web is
always cookies and JWT is getting popular lately.

~~~
unscaled
Only partially correct. I think the earliest drafts of OpenID Connect were
completely agnostic of JWT, and so is OAuth 2.0, but the final Open ID Connect
Core spec is tightly coupled to the JWT standard in multiple places.

The first and most important coupling point is the ID Token. There are three
types of tokens issued by Open ID Connect: Access Tokens and Refresh tokens
are opaque, just as in OAuth 2. ID Tokens, on the other hand, most follow a
more-or-less well-defined JWT format (as much as JWT can be well-defined - it
is a somewhat wild west of a standard).

The rest of the places you could use JWT are in the spec, but I admit I've
never seen them in the wild (and I would probably avoid them like the plague
if I was trying to implement a _secure_ subset of an OpenID Connect IdP):

1\. JWT request signing (and even encryption!) 2\. JWT for signing and
encrypting any JSON response 3\. JWT for client authentication 4\. JWT for
aggregated claims

And I may have missed more things.

If you want to implement Open ID Connect without being crazy, forget about all
of these and only use/implement the Auth Code flow with a client secret. You
should still verify the ID Token according to the spec, but if you fail to
verify it's no longer an issue, since this is a value you get directly from
the the Authorization Server on an authenticated TLS channel (the same channel
you'd trust for getting the ID Token signing keys).

~~~
user5994461
OpenID Connect predates JWT so it certainly couldn't have been used from the
beginning. I'm not aware if there is a re edition of the spec.

Either way, pretty much everything in OpenID Connect is optional and/or
implementation specific. OIDC providers have to be integrated one by one,
adjusting to their slight differences.

~~~
TJSomething
OpenID Connect Core, section 2: "The ID Token is represented as a JSON Web
Token (JWT) [JWT]." ([https://openid.net/specs/openid-connect-
core-1_0.html#IDToke...](https://openid.net/specs/openid-connect-
core-1_0.html#IDToken))

~~~
user5994461
Well, that's good to know on the one hand. On the other hand, I've never seen
a provider that respected that section in full.

~~~
unscaled
This is more or less one of the _only_ part that is respected in full.

I've got to say, I've seen providers without proper discovery, I've seen
providers with strange hybrid flows and I'm pretty sure most providers don't
implement the request/response signing and encryption (after all, if you want
insanity, you'll be more than happy with SAML). But I've never seen a provider
who doesn't implement an ID token.

I think everybody would agree that OpenID Connect without an ID token is just
plain OAuth 2.

~~~
user5994461
I've had providers with blackbox tokens. Basically a random string that has to
be passed to the /userinfo endpoint to retrieve the user claims.

I've had providers with the id_token and access_token being the same value.
Other where they were different values. One that didn't support refresh_token
at all.

Then a variety of screw ups where the required claims in the JWT tokens are
missing or incorrect.

It's wild really. It always takes a bit of work to integrate any OpenID
Connect provider. Most libraries only care to handle Google or Facebook login.

------
toyg
I guess (hope?) this is actually as a result of some communication failure or
refusal behind the scenes. Otherwise it would look pretty rude.

Some sort of accompanying commentary from OIDF people, explaining the
reasoning behind the letter, would be appreciated.

~~~
will4274
I dunno.

It's also pretty weird to borrow 95% of a spec, miss out on a half dozen
important security features, not acknowledge the relationship between your
work and the spec, and not contribute back to the community that funded the
spec.

~~~
tptacek
The big tech companies all tend to have excellent security teams, each of
which have particular strengths. Google's obviously includes low-level
vulnerability research and browser security. Apple's includes hardware
security and cryptography. I would be surprised if they "missed out on a half
dozen important security features".

~~~
will4274
The article describes the missing security features. Did you read it?

The lack of nonce makes replay protection impossible. The lack of c_hash opens
up vulnerabilities in connect flows where the service incorrectly assumes the
two tokens refer refer to the same user. Returning the id token on the query
leaks it in the Referer header.

~~~
tptacek
I don't know enough about Sign In With Apple to map its security features to
those of OpenID; I'm guessing you don't either.

~~~
jogux
Neither of you need to; the article contains a link to
[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) where a bunch of experts have analysed
the current (beta) signin with Apple against the spec. In particular it's
"signing with apple on the web" that they've analysed, which is open for
anyone to analyze using the developer tools in a browser etc.

Apple are actually following the OpenID standard, that's why the list is
differences is concise and to the point. Several of the pieces that are
missing/different are items that were added to OpenID to prevent attacks that
have been used against pure OAuth 2.

Many of the potential attacks relate to fooling the third party sites as to
what happened, so it is difficult/impossible to mitigate them with magic on
Apple's side.

(disclaimer: I'd listed as a contributor on above doc. I'm writing here in a
purely personal capacity.)

~~~
ksec
>The big tech companies all tend to have excellent security teams, each of
which have particular strengths. Google's obviously includes low-level
vulnerability research and browser security. Apple's includes hardware
security and cryptography. I would be surprised if they "missed out on a half
dozen important security features".

>In particular it's "signing with apple on the web" that they've analysed,
which is open for anyone to analyze using the developer tools in a browser
etc.

Why is it I am getting the idea Apple just aren't very good with the web. I am
reading it as Sign In with Apple ID is secure on the devices, iOS and App, but
not when used on the web.

------
jchw
Everyone is obviously focusing on the certification suggestion, but they also
went and made a nice document of “bugs.” If Apple does anything, patching some
of the larger deviations would be great, just out of sheer convenience. Third-
party auth libs already have enough exception cases for specific services...

------
slics
It’s not an issue with $15k or if apple can pay or not. I think it’s the issue
of Apple vs. Open in general. Apple’s echo system is closed to the world.

~~~
reaperducer
_I think it’s the issue of Apple vs. Open in general. Apple’s echo system is
closed to the world._

I think that for people outside of HN, that's OK. Not everyone trusts the open
source community, or open source organizations.

If something goes wrong with something important, it's normal for people to
want something or someone to blame. If that something is Apple, that's useful.
If it's some rando on the internet contributing code to a code repository,
it's significantly less useful to the ordinary person.

For the average person, entrusting Apple with their logins is a better option
than using password1234 or some other coping mechanism. People know Apple.
Nobody knows OpenID. It's the same reason people used to trust Microsoft (and
many still do!) with their personal information. Microsoft is a known
quantity.

It's like having a neighbor watch your pets while you're on vacation, or
signing up with some random service on the internet to watch your pets. Those
random services get bonded and insured for the peace of mind of the user.
There is no such level of assurance from OpenID other than it uses the word
"open" in its name, and as a culture we value the word "open" more than
"closed."

~~~
damnyou
One of the big cultural problems in society today, and (antitrust) law in
particular, is the focus on consumer welfare above all else. The consumer is
not the only thing that matters

~~~
hidden_anomaly
Can you expand on this idea? This is the first time I’ve heard anyone saying
that consumer-first is wrong.

~~~
damnyou
Lina Khan is one of the leading proponents of the idea:

[https://www.nytimes.com/2018/09/07/technology/monopoly-
antit...](https://www.nytimes.com/2018/09/07/technology/monopoly-antitrust-
lina-khan-amazon.html)

The consumer uber alles idea is actually pretty new in the history of
antitrust law.

------
frenchman99
They basically just asked Apple to give them 15K$, which is the cost of
membership for a company of more than 100 employees [0].

Is it currently not possible to use standard OpenID clients for "Sign-in with
Apple" authentication ? Does Apple not provide some sort of SDK that makes
this easy ? And if so, what is the advantage of "Sign-in with Apple" being
interoperable ?

[0]
[https://openid.net/foundation/members/registration](https://openid.net/foundation/members/registration)

~~~
hprotagonist
$15k feels like so trivial an amount to apple. It’s the sort of expense you
don’t even need to file an expense report for on a corporate credit card if
you’re even a mid-level manager there.

edit: not “no expense report”; i actually meant “you don’t have to ask anyone
first (but will have to file a report about it later)”, which is not quite the
same thing.

~~~
CydeWeys
I guarantee you'd have to file an expense report, but that's probably the
extent of it.

~~~
Zenbit_UX
Of course you need to file an expense report, his point was it's such a
trivial sum to Apple the person expending it wouldn't need to ask permission.

------
nereid
It is not just ask for money, They are proposing that Apple use the standard
and make public they use the standard, It could boost openid as no other could
make.

~~~
buboard
Doesnt google already use it?

~~~
cameronbrown
Yep, Microsoft too. Apple supporting the standard would be a great help to
developer adoption.. theoretically, though I think they just prefer strong-
arming developers into using their proprietary API anyway, standard
irrespective.

------
ForHackernews
ITT: People who benefit from standard protocols and use OpenIDConnect every
single day without realizing it complaining that the world's first trillion
dollar company might have to pay 0.000015B.

~~~
patrickmcnamara
It wouldn't be this way with other companies. Hackers news will defend Apple
no matter what for some reason.

~~~
Octoth0rpe
Except their keyboards.

And their laptop overheating.

And the price of their monitor stands.

Or their lack of a <5" screen phone.

No, hacker news is happy to bitch about apple all day long and I don't know
how one could possibly think otherwise.

~~~
gingerlime
... and USB-C ... and MagSafe ... and lack of headphone jack

~~~
Ensorceled
... and getting rid of MagSafe and their “walled garden” and the 30% they
take.

------
jjtheblunt
Perhaps Apple has intentionally NOT jumped on the OpenID effort without
tweaks, for the following reason?

Quoting wikipedia for convenience:

"OAuth 2.0 has had numerous security flaws exposed in implementations.[17] The
protocol itself has been described as inherently insecure by security experts
and a primary contributor to the specification stated that implementation
mistakes are almost inevitable.[18][19]".

~~~
jogux
Apple are using OAuth 2.0.

The contributor referred to (John Bradley) as saying that OAuth 2.0
implementation mistakes are almost inevitable is one of the authors of the
OpenID Connect spec, and if you follow the citation link (
[https://mailarchive.ietf.org/arch/msg/oauth/WuT1tmFoxs8S_2v7...](https://mailarchive.ietf.org/arch/msg/oauth/WuT1tmFoxs8S_2v7kYmouF_ZVFo)
) you'll see him mention that the flaw referred to is fixed in OpenID Connect.

------
huffmsa
Par for the Apple course isn't it?

> _Oh, you 've all agreed on USB type-c? Well we're going to use thunderbolt.
> Except for when we don't and our customer have to buy a type-c to
> thunderbolt adapter._

> _Two button mouse with a scroll wheel? How about a 1 button mouse that you
> click with two fingers._

> _Linux? Sure, but it 's called MacOsx and doesn't have a native package
> manager._

They've always done stuff like this.

~~~
TheCoreh
> Oh, you've all agreed on USB type-c? Well we're going to use thunderbolt.
> Except for when we don't and our customer have to buy a type-c to
> thunderbolt adapter.

Assuming you're referring to Lightning, that predates USB-C, and the reason
why Apple hasn't replaced it yet is probably because of agreements with
accessory makers over how long they are going to remain using that connector.

> Two button mouse with a scroll wheel? How about a 1 button mouse that you
> click with two fingers.

I believe macOS originally didn't have the concept of right click, but rather
ctrl-click. Eventually they supported both, and mice sold by Apple have
supported right click for almost 10 years.

> Linux? Sure, but it's called MacOsx and doesn't have a native package
> manager.

Linux (the kernel) doesn't have a package manager, and many distributions
don't have a package manager either. The primary use of macOS is not the
command line, and developers are better served by third party package
managers/repositories, with a cadence independent of the OS release lifecycle.
(Just like on Ubuntu, where you frequently need to add PPAs for anything
newer/different from what's available upstream)

~~~
arendtio
Just out of curiosity: Which Linux distributions come without a package
manager?

The only one I am aware of is LFS (Linux From Scratch), which is more like a
manual on how to build your own distribution than a distribution like others.
Anything more mainstream?

~~~
vageli
Slackware has no package manager.

~~~
toyg
Uh, that depends on your definition of a package manager. Slack has had
utilities to install and uninstall packages for ages, if i remember correctly,
and in the most recent release it might even have something that works with
remote repos.

But yes, I agree that a pkgmgr is not necessarily a prerequisite in the Linux
world, plenty of smaller distros don’t have it.

------
pyman
One of the biggest benefits of building a close platform is that you have the
freedom to ignore open letters like this one.

------
MaxBarraclough
Sounds like another case of Apple doing things in a nonstandard way for little
reason, getting the security wrong, and paying the price. A while back, their
iMessage system was found to have rather serious security issues. Same same.

'Not Invented Here syndrome'.

------
alt_f4
I'm surprised how many people seem to have a huge problem with Apple, a 910
billion dollar company, paying 15k towards a membership of an organization
that underpins the major ideas in their software implementation. That's, what,
a single Mac Pro?

~~~
user5994461
You're giving too much credit to the foundation. OpenID was an organic effort
on authentication before it became a design by committee, the root would be
somewhere at Twitter or other big web companies very long ago.

OpenID Connect is not an authentication solution by the way. It's at best a
few standard requests and parameters, all of which are optional, that could be
used to interconnect authentication systems if that's what you're trying to
do. Authentication and most of everything is left to the implementation.

------
Sephr
"Therefore the OpenID Foundation invites Apple to: [...] Join the OpenID
Foundation"

It's not really an "invitation" if they expect Apple to give them money.

~~~
thefounder
Let's start a crowdfunding campaign to pay for the Apple's membership. 10k
shouldn't be that hard to get given the amount of time we, developers, have to
spend on Apple's custom implementation.

~~~
toyg
Holy sheet - don't give them ideas, man! Apple are skimpy enough as they
are...

------
marmada
It's interesting to see the pro-Apple bias on Hackernews, if some other
company tried to avoid integrating with existing standards, thus hurting
interoperability I bet HN would throw a fit.

~~~
dang
Perceptions of HN bias tend to be in the eye of the beholder. They're mostly
an inverse image of what you like: if you like X, HN will seem anti-X; if you
dislike it, HN will seem pro-X. In reality, HN is a large dataset that
contains all of these things. But we have a cognitive bias to notice more of,
and more intensely, what rubs us the wrong way. Pain cuts deeper grooves than
pleasure.

After a few cases, the unpleasant memory hops to the dataset as a whole,
leading to a fixed view of HN. But people with opposite likes have the
opposite fixed view. When people tell how they see HN, they're really telling
the story of themselves. It's fascinating how solid this principle turns out
to be. I'm sure it extends to things that are far less trivial than an
internet forum.

