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.
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.
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.
>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.
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.
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.
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).
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.
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.
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.
OpenID Connect predates the final JOSE RFCs, but not the drafts. It was not published by IETF, so it allowed itself to refer to internet drafts describing JWT before being released. The JOSE RFCs and Open ID Connect were basically authored by the same people (M. Jones, J. Bradly, N. Sakimura).
Spot on - in fact over time what we're seeing happen is the authors of the OpenID Connect standards submitting the parts as RFCs to the IETF. The OpenID Foundation is able to move a lot faster than the RFC process whilst coming with similar benefits of protection against patents etc. Obviously there's always speed vs quality tradeoffs, but given the number of interoperable OpenID implementations and the adoption into various openbanking systems (e.g. the UK OpenBanking standards) then it seems like (with the benefit of hindsight) the OpenID Foundation made some good choices.
Strange that the examples given are heavily skewed towards websites in Japan (Gakunin, Nikkei, Tokyu, Mixi, Yahoo Japan, Softbank). Also, I guess they ought to be updating that text now that Google+ is dead.
The brand Google+ is dead, the sign on service that was part of its API lives on in the Google Identity Platform. If you ever click "Sign-On With Google" you are using it. If you use a different authentication provider - like Github or Facebook or Linked In, you are still using Open ID Connect. Its actually bizarre that Apple did this the way they did.
The writer is Japanese, so he might be basing this on personal experience. This is not a good list to sway Apple with, even if they had experience with Japan. The first 3 are not tech companies. Tokyu in particular is a huge conglomerate and they have many different companies with separate user bases. I've never seen any of them using OpenID Connect.
Yeah, I think there must be more to it than Apple not knowing about OpenID - it was probably deliberate for some reason, would be interesting to know what it was.
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.
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".
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.
Neither of you need to; the article contains a link to https://bitbucket.org/openid/connect/src/default/How-Sign-in... 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.)
>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.
It's very "pirate of Silicon Valley", i.e. very old-school Apple: "so sue me". Regardless, the right answer is to engage privately first, to see why they missed that 5% and if there is any way to find agreement, not to go pedal-to-the-metal with public shaming.
As someone who's tried to contact Apple before, posting publicly is about the only thing that would ever work. Good luck getting in contact with anyone there who'll speak to you. They're worse than most other companies, and most other companies are already quite bad.
For an individual, yeah. Apple belongs to a number of standards bodies and consortia, though; when they deviate from an existing standard, they usually do do more deliberately than this letter implies.
I just don't get why you're so stuck on this one point on etiquette. To me, saying "We tried to contact you to no avail" is ruder than omitting the line.
An open letter is obviously not a communication to the recipient, but to the public. It's a rhetorical exercise you use so that the public will put pressure on the counterpart; hence it has to win the public to your side. In order to have the public on your side, you have to be as clear as possible about your motives and your methods - otherwise you'll get people questioning them, which is exactly what you can see in this thread. That's a fail. A simple paragraph saying "we tried to engage with you but could not because X" would have made the writer more sympathetic to the public, imho, and avoided most of the challenges you see here.
If that looks rude to the counterpart, it doesn't really matter; everyone knows any politeness is fundamentally insincere anyway, because if one had not wanted to ruffle their feathers, one wouldn't have published anything in the first place.
> It's 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.
A good friend is on one of the product teams at Apple that had a recent release around WWDC. Their new product (realitykit) basically made a couple of well known startups in the space irrelevant overnight.
So I asked my friend if he knew about these other companies, again all very well known in the specific market for AR developer tools, and he said he didn't and they don't actively look for companies they might be impacting when making product decisions.
The difference is that OpenID is not a 'well known startup' but an industry standard and that Apple obviously implemented the well-known protocol 'OpenID Connect' but added some bugs and didn't want to mention that their technology could be compatible with the existing one.
And I don't want to downplay the innovative additions Apple made to the whole thing (browser integration etc.), but it doesn't make an honest impression if you don't mention that your revolutionary product is a based on a well-known standard.
> and didn't want to mention that their technology could be compatible with the existing one
Really curious for the reason behind that. If they would've mentioned it there probably would have been quite a bit less of lock-in criticism for the product. But maybe they are also banking on the devs not realizing that they aren't that locked in and have an easy option to move away.
I suspect they didn't mention it because they see the lock-in to their product as a feature. Mentioning OpenID might give the impression that Apple would be interested in interoperability (to some degree).
The main requirement therein I would say is that you can't use OpenID to describe an implementation unless it implements the mandatory-to-implement parts of the relevant protocol specification (and all the specifications are 100% free; e.g. https://openid.net/specs/openid-connect-core-1_0.html ). That's more about interoperability than anything else.
"Use the OpenID Connect Self Certification Test Suite to improve the interoperability and security of Sign In with Apple."
Give us a bunch of money and maybe we'll let you join our little group and you can have our mark of quality that you are now secure. Wow, really? Thanks.
It's a little like a lot of the spam I get as an Android developer from "marketers" and just general weirdos trying to get rich off my hard work.
It’s been a couple weeks since I’ve seen this “optics” being thrown around in comments here. Why you keep using this term when the more appropriate one would be “perspective”?
Apple are absolutely 100% free to run the tool and fix any issues found without any payment to anyone except their own engineer's time.
(There is a fee to pay for the 'OpenID Certified' logo and to be listed as certified, but in my opinion just running the free tool and fixing any interoperability issues is a major benefit by itself.)
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...
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.
Knowing nothing about Apple's specific case, I have been involved in the decision at major companies to deviate from common standards, which is not done lightly, on many occasions and worked with standards organizations to smooth over the fallout. In my experience, when a company the size of Apple deviates from a standard, there are pragmatic and arguably justifiable reasons behind the scenes.
The typical driver is that the standard is a poor fit for purpose because it was originally designed by companies operating under a more limited set of constraints and use cases. In some of the cases I've been involved in, the deviations required to make it fit for purpose would immediately save millions of dollars per year versus following the strict letter of the standard, so the value of deviating was not academic. The reason you keep any deviation close to the standard instead of designing a new one is to minimize the interoperability gap in practice.
If you are able to articulate why the standard is not fit for purpose to the standards organizations, they may use it as a driver for a new standard. However, this frequently runs into strong political resistance from the existing member base because they rarely benefit from the increased scope -- all downside, no upside. Nonetheless, the standards organizations are invested in maintaining relevance. As a practical matter, unless you go into these discussions with the standards orgs with an existing implementation of an alternative that threatens their existing standard, they are very reluctant to move.
I'm not saying any of this applies to Apple's case but the above happens a lot in my experience. It would be nice if it was easy to work with the standards organizations if you need to make a standard work for other use cases but in practice it is an extremely difficult and political uphill battle.
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."
But this is not an issue of Apple vs. OpenID Connect, but one between Apple’s flawed implementation of the OpenID Connect standard vs. the actual OpenID Connect standard. If they would have just gone with some proprietary implementation I very much doubt the OIDC people would have bothered. That happens pretty much daily after all.
Apple - like every commercial vendor - is responsible for their products and services whether or not they use open source software and open protocols to implement them. Every service on the internet relies on open standards, it doesn't change their liability.
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
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 ?
I doubt 15k is really an issue for Apple. You could even say that at its scale its Apple's duty to pay that membership and give back contributing to the specifications.
Using standards has some advantages like not having to test dozens of authentication systems/clients doing basically the same thing. If you would have read the document you would have found that you can't use standard openID clients due some issues with Apple's implementation. Some of the issues have security implications.
No, you just test slightly different implementations of the same standard, that seem to interoperate until they don't, even among products from same vendor.
No, they laid out several issues with Apple's OpenID Connect implementation with one of them being an actual security-related issue (missing nonce which can enhable replay and csrf attacks). You only have to pay if you certify and even then, 15k is not that much.
$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.
> 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
You're probably joking, but in case you're not this isn't right. If a company had a policy like that they would have difficulty demonstrating to the IRS that all their expenses really were for their business, and they would have a hard time protecting themself from embezzlement. The company needs to be keeping a receipt and a business justification for the expense.
The advantage of "Sign-in with Apple" being interoperable means that networks of relying parties (e.g., national research and education networks) can readily provide Apple customers access to high-integrity services. Both kinds of LOA—identity proofing and identity binding—are really difficult to do without secure hardware, and it could drive Apple product sales if they make LOA easy to do with their stuff (like TouchID or FaceID).
Not all employees working at or directly for Apple make Apple salaries. All the contractors they hire are likely to bring that median down significantly.
18 months? That would make the median hourly wage ~$5.20
I don't think that's right. Perhaps you meant 18 weeks?
It's still irrelevant, as it's not a something an individual is paying. The parent comment merely scales Apple's cash on hand to numbers we can understand.
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.
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.
Twitter and Facebook are the big two holdouts besides Apple that makes social sign in buttons a PITA. OpenID Connect can already provide MS and Google and also supports Paypal, Yahoo, AOL, etc.
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.
I’m a prototypical Apple fanboy, who thinks most of the criticism directed at Apple on HN is silly. Yet I completely agree with the OpenID Foundation here.
If I had to guess, the criticism here comes from the same strain of criticism of the GPL that has been growing over the past years. The tech community has grown a lot, and has attracted a lot of people mostly interested in money. Ideas such as open standards or non-commercial collaboration have lost some appeal.
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]".
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... ) you'll see him mention that the flaw referred to is fixed in OpenID Connect.
> 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.
> 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)
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?
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.
Further, regardless of the rationale, the point still stands that Apple has never really played nicely with the rest of the tech world.
But when you're the big fish like they are, a lot of people feel like you're morally obligated to take a contributory, if not directorial role in steering the industry. And Apple doesn't do that.
And of course development on the Mach kernel started in 1985.
The Unix personality on top of Mach was derived from BSD 4.3, released in 1983. BSD itself was started around 1977. It all is derived from the original Unix.
Classics Mac OS isn’t based on NeXTSTEP; Mac OS X is, and the Mach kernel in particular is much older than Linux. It takes like thirty seconds of googling to get your history straight.
Me neither. In 1997, Apple bought NeXT to get Jobs back. In the bargain they acquired NeXTSTEP, which was, by then, a mature and robust OS. Once Jobs was back in charge at Apple, he deemed classic MacOS unsalvageable, and decided to move the Mac to NeXTSTEP - an OS they already owned and which he was obviously familiar with. It took a few years to build what would be known as Cocoa and Carbon, and eventually OSX. Linux was never even in the picture.
Tried the 1 button mouse in an apple store yesterday, holy S* the page scrolling feature is so bad, you have to 'track pad' it in a limited space on the 3d curved surface. soooo annoying.
The laptop trackpads with 2 finger touch are great. Having to consciously think "I need to click in the bottom right corner to right click" on non-apple laptop is cumbersome.
It does work but I've yet to encounter one that works as well as the Apple one. Like how the 1 button mouse works, but the two button one works more better.
Though I was moreso talking about the OG hockey puck that shipped with the OG iMac.
I'm using Apple touchpad right now (and a non-Apple one too, right next to it) and it's nothing special. The only thing that makes it pleasant to use is the way gestures are implemented in macOS - but it has nothing to do with two-finger click. This works just as well, or even slightly better, on my non-Apple laptop with GNU/Linux and it's been a while since I've encountered a touchpad that would be worse in this regard (they definitely existed many years ago though).
On my Thinkpad X240's touchpad, 2-finger touch is quite natural feeling. To right click, I just have the second finger touching somewhere in quadrant I. Just an example.
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.
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?
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.
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.
Beyond that, legally, anything you buy needs to have the seller invoke a concept called an invitation to treat[0] which in modern times is usually established at the point of issuing a receipt or tax invoice.
Even if someone has paid for something, the seller does not have to recognise that a transaction has taken place and would not have to enter or execute the contract. This is especially important in times where there might be a pricing error or something.
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.
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.
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.