Open Letter from the OpenID Foundation to Apple Regarding Sign in with Apple
openid.net
openid.net
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.
Also, by my reading, the problem is that the standard requires the nonce parameter to do something and Apple ignores it.
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.
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.
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).
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.
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 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.
From example, the request object in OpenID Connect (that can prevent authorization request parameters from tampering) is only just now coming out as an RFC https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19
Some sort of accompanying commentary from OIDF people, explaining the reasoning behind the letter, would be appreciated.
"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.
But it's mostly not their work - Apple's protocol is basically a bad implementation of OpenID Connect.
But the reason is because "optics" and "perspective" don't mean the same thing.
https://github.com/openid-certification/oidctest
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.)
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.
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.
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.
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.)
>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.
they all been doing this all the time
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.
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.
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.
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.
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."
https://www.nytimes.com/2018/09/07/technology/monopoly-antit...
The consumer uber alles idea is actually pretty new in the history of antitrust law.
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.
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 ?
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.
$15k is something like 0.000006% of Apple's cash on hand.
$15,000 would be between a week and just over a month of compensation.
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.
Not really...
For example, the lack of a discovery document means that a lot of the essential configuration cannot be discovered programmatically.
The lack of a UserInfo endpoint means that applications which are used to using that will need to get the user info out of the id_token.
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.
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.
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.
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.
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.
They've always done stuff like this.
It's never felt as natural on their mice though.
Though I was moreso talking about the OG hockey puck that shipped with the OG iMac.
You realize that Apple was doing one-button mice from before (almost) everyone else was doing mice, period, yes?
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)
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?
But yes, I agree that a pkgmgr is not necessarily a prerequisite in the Linux world, plenty of smaller distros don’t have it.
OsX was built on NeXTSTEP, first demoed in 1988 and released in 1989.
Linus started working on a minix clone in 1991, with the first complete distributions (Slackware and Debian) not appearing before 1993.
Not talking about classic MacOs
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.
'Not Invented Here syndrome'.
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.
It's not really an "invitation" if they expect Apple to give them money.
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.
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.