OpenID Foundation Says 'Sign In with Apple' is Not Secure Enough

The OpenID Foundation, the organization behind the OpenID open standard and decentralized authentication protocol, has penned an open letter to Apple in regards to the company's recently announced "Sign In with Apple" feature. From a report: In its letter, the organization said that Apple has built Sign In with Apple on top of the OpenID Connect platform, but the Cupertino company's implementation is not fully compliant with the OpenID standard, and as a result "exposes users to greater security and privacy risks." "The current set of differences between OpenID Connect and Sign In with Apple reduces the places where users can use Sign In with Apple and exposes them to greater security and privacy risks," said Nat Sakimura, OpenID Foundation Chairman.

The OpenID Foundation published a list of differences between Sign In with Apple and the OpenID Connect platform, which Sakimura urged Apple to address. The OpenID exec said these differences place an unnecessary burden on developers working with both OpenID Connect and Sign In with Apple, who now have to support two different authentication standards and deal with each one's quirks. "By closing the current gaps, Apple would be interoperable with widely-available OpenID Connect Relying Party software," Sakimura said.

PGP/GPG with password-based key manager

[Anonymous Coward]

That's the only way. Passwords should be for local maintenance of your cryptographic keys.

That being said, websites should allow each user to specify multiple keys for login (like having multiple passwords). That way, a user doesn't even need to move private keys between devices—a user just generates a private key on each device, and maybe uses a transient password/2fa means by which to register it with the service in question.

Of course, if a user wants to transfer a private key around, that should be

If Apple cared about interoperability

[cdsparrow]

They would have just made it work with openid connect. Probably took more work to break interoperability, so was likely on purpose...

Re:

[Anonymous Coward]

It's because Apple is literally forcing companies to implement it, if they want access to the iOS store.

If you offer logins through Google or Facebook, you are required to also implement Apple's stupid scheme.

If they didn't do this, literally no one would bother implementing it, because what's the point? Apple controls something like 15% of the total market, it's just not worth it. (Keep in mind most iOS apps these days are written using tools that target both iOS and Android, so you get the iOS version "fo

Home Depot has monopoly position in its tool store

[Anonymous Coward]

You keep using that word, "monopoly". I do not think it means what you think it means.

Not at all true

[SuperKendall]

It's because Apple is literally forcing companies to implement it, if they want access to the iOS store.

Wrong, as we'll see in a moment...

If you offer logins through Google or Facebook, you are required to also implement Apple's stupid scheme.

And if you don't, you also do not have to support Login With Apple, and can be in the App Store. Yes in 2019 it is still not mandatory a company use GooBook technology to support user accounts.

If they didn't do this, literally no one would bother implementing it

That's plainly wrong, because why would you NOT implement this if you didn't want to stand up your own auth server? The fact that it works with FaceID right out of the box and will be inherently more trusted by users is a compelling reason to use it.

On top of that Apple is giving you a free indicator as to how likely it is the user logging in, is not a resource-wasting bot.

Apple controls something like 15% of the total market,

But 90% of the non-bot / people with more than $10 market.

Keep in mind most iOS apps these days are written using tools that target both iOS and Android

As an iOS developer I can assure you those remain a tiny fraction of the IOS market because all you get out of that are sub-par apps.

I don't think it's going to end the way they think it will.

Are you saying that companies ar going to leave the iOS App Store rather than implement the very easy to support Login With Apple?????

ARE YOU SERIOUSLY SAYING THAT?

Bwahahahah ahha haha haahahahahaha!!!

Re: Not at all true

[Anonymous Coward]

If you read the article (or maybe the actual complaints) you'd see they also found security flaws. For example, Sign In with Apple tokens never expire and requests for them do not use a nonce. (Can you say, "replay attack?")

Plus you don't need to leave the App Store to skip this insanity: just never update your app once the new rules go in place and wait for Apple to pull their head out of their ass.

Sign In with Apple offers me nothing as a developer. Why bother?

Re:

[guruevi]

Apple iOS is a bit larger than 15%. Apple's iPhone market share is 25%, next up is Samsung.

Yes there are more android devices but the majority aren't usable mobile phones, the Apple App Store has twice the revenue of Google App Store.

Android has a large market share but the application markets are split between Google, Amazon and Samsung with various Chinese and 3rd party App Store. As a developer, targeting Android is hard. Not only do you have to build for up to 5 major versions but also for hundreds of d

Re:

[Tough Love]

Apple iOS is a bit larger than 15%. Apple's iPhone market share is 25%, next up is Samsung. Yes there are more android devices but the majority aren't usable mobile phones and blather bather fart burp ooh blather blather blather on

You are full of putrid shit like the ass-licking Apple lapdog you are. Samsung and Huawei crush Apple's smartphone global market share [zdnet.com]

Re:

[Tough Love]

Apple iOS is a bit larger than 15%. Apple's iPhone market share is 25%, next up is Samsung. Yes there are more android devices but the majority aren't usable mobile phones and blather bather fart burp ooh blather blather blather on

You are full of putrid shit like the ass-licking Apple lapdog you are. Samsung and Huawei crush Apple's smartphone global market share [zdnet.com]

Thug Apple thinks that sending asshole troll mods to mod down facts will change the facts. Here's a fact: thug Apple is full of putrid shit.

Re:If Apple cared about interoperability

[Antique Geekmeister]

It sounds similar to what Microsoft did with Kerberos, the authentication protocol used by Active Directory. MIT Kerberos was and is completely open source. Microsoft extended certain standards and make it incompatible with MIT Kerberos servers. Some of the distinctions and standards violations are documented at https://www.usenix.org/techses... [usenix.org] . Fortunately, the administrators of MIT Kerberos were able to quickly adapt their code to enable compatibility with Microsoft's extensions: this would not have been possible with a vendor manipulated, closed source software base and API.

Is there a similar document for this Apple vs. OpenID incompatibility?

The referenced list of problems

[Anubis IV]

You have to go through three links to find the actual list of concerns that's referenced in the summary [bitbucket.org]. I'll save you the time of tracking down the links. Some of the high points:

Spec Violations

• When nonce is provided in the code or code id_token grant types, it isn’t included in the id_token returned.
• • Not having the nonce removes the protocol's ability to thwart Cross Site Request Forgery Attack.
• The code id_token response type does not include c_hash in the returned id_token.
• • It makes it possible for Attackers to insert the authorization code they have obtained (Code Insertion Attack).
• The code id_token response type returns the response parameters including id_token and code as query parameters, not in the fragment.
• • It makes ID Token and Authorization Code potentially leak through referrer etc. ID Token is a set of personal data and leaking it will pose privacy risk. An authorization code obtained by the attacker in this way may be used for the Code Insertion Attack.
• Providing a prompt parameter with any value (e.g. login or consent) or empty results in a 400 with no body.
• • Not being able to ask for explicit consent increases the privacy risk for end users.
• When max_age is requested, the id_token does not include an auth_time claim.
• • The Client may want to limit access to protect the user if the authentication at the Provider was done too long ago but the lack of support for max_age does not allow for such a decision.

There's more at the link, so go there if you're interested in seeing "peculiarities", things Apple has already fixed, and other details.

Re:

[93 Escort Wagon]

Sounds somewhat loosely analogous to when Microsoft rewrote its TCP stack to remove the BSD code - they basically ended up having to re-learn a lot of security lessons the BSD folks had learned (and addressed) years before. Here, Apple will likely be rediscovering security lessons the OpenID folks already figured out.

But it's not like Apple is doing anything wrong. OpenID has a pretty permissive license [openid.net] which basically says "do what you want with our code, as long as you give us credit". And OpenID isn't co

Re:

[the_B0fh]

remember when security researcher Stefan Esser spent 10 months pleading with Apple to fix a zero-day in macOS

No I don't remember him pleading with Apple.

https://www.intego.com/mac-sec... [intego.com] basically states that Esser does not inform Apple and basically just tweets about things. He also does not do the responsible disclosure that most security investigators subscribe to.

This is how the article ends:

Was Stefan Esser and his company SektionEins right to publish details of the vulnerability without informing Apple privately first? Would a co-ordinated disclosure of the flaw have been safer for the Apple community? Or is Esser performing a valuable service that keeps Apple's engineers on their toes?

Re:

[kqs]

[raises hand] I do. They've shown that they care about security and privacy. The OpenID protocol has gone through multiple revisions, fixing problems as they are learned. Nothing is perfect, but OpenID is very very good (within its design limits) and companies should not ignore the lessons learned.

Federated ID is very useful; I have "Accounts" on dozens (hundreds?) of sites, and most of then have crappy security. Good security is hard. But if you use OpenID, it's much easier to get right, and you get m

Interoperable

[p91paul]

"By closing the current gaps, Apple *would be interoperable* with widely-available OpenID Connect Relying Party software" Considering their history, at Apple the lack of interoperability is considered the most important feature.