OpenID Foundation says 'Sign in with Apple' has critical gaps, urges changes
The OpenID Foundation this week issued an open letter to Apple's Software Engineering chief, Craig Federighi, arguing that the upcoming "Sign in with Apple" standard bears a lot of similarity to OpenID Connect -- but not enough for privacy, security, and development purposes.
"The OpenID Foundation applauds Apple's efforts to allow users to login to third-party mobile and Web applications with their Apple ID using OpenID Connect," the letter begins, elaborating that Connect is a "modern, widely-adopted identity protocol built on OAuth 2.0 that enables third-party login to applications," and was "developed by a large number of companies and industry experts" within the Foundation.
While Apple appears to have "largely adopted" Connect in building Sign in with Apple, there are a host of differences that shrink the places where Apple's system can be used and expose it to privacy and security threats, the Foundation said. An example of the latter is absence of PKCE in the Authorization Code grant type, which could nominally leave people exposed to code injection and replay attacks.
The schism also allegedly "places an unnecessary burden" on developers working with both Connect and Sign in with Apple, particularly since Apple's code isn't compatible with OpenID Connect Relying Party software.
The letter asks for Apple to "address the gaps," use the Open ID Connect Self Certification Test Suite, state that Sign in with Apple is compatible with Relying Party software, and finally join the OpenID Foundation.
Testing of Sign in with Apple will start later this summer ahead of iOS 13's fall launch window. The technology is intended to be a more privacy-focused alternative to sign-in buttons from the likes of Facebook, Google, and Twitter, but Apple has been criticized for making support mandatory if those third-party options are present.
"The OpenID Foundation applauds Apple's efforts to allow users to login to third-party mobile and Web applications with their Apple ID using OpenID Connect," the letter begins, elaborating that Connect is a "modern, widely-adopted identity protocol built on OAuth 2.0 that enables third-party login to applications," and was "developed by a large number of companies and industry experts" within the Foundation.
While Apple appears to have "largely adopted" Connect in building Sign in with Apple, there are a host of differences that shrink the places where Apple's system can be used and expose it to privacy and security threats, the Foundation said. An example of the latter is absence of PKCE in the Authorization Code grant type, which could nominally leave people exposed to code injection and replay attacks.
The schism also allegedly "places an unnecessary burden" on developers working with both Connect and Sign in with Apple, particularly since Apple's code isn't compatible with OpenID Connect Relying Party software.
The letter asks for Apple to "address the gaps," use the Open ID Connect Self Certification Test Suite, state that Sign in with Apple is compatible with Relying Party software, and finally join the OpenID Foundation.
Testing of Sign in with Apple will start later this summer ahead of iOS 13's fall launch window. The technology is intended to be a more privacy-focused alternative to sign-in buttons from the likes of Facebook, Google, and Twitter, but Apple has been criticized for making support mandatory if those third-party options are present.
Comments
Apple will most likely address any valid security issues from OpenID's complaint before release.
And, quite frankly, I couldn’t care less how Facebook and google are conducting their business. I just care that Apple gets it right.
I don't care that devs have to right new code for Apple alone.
I don't care that OpenID says Apple's implementation 'has gaps'.
I don't care that Apple makes it mandatory to use Sign In with Apple if Sign in with Google/FB is used.
-(Actually, I do. I like that.)
I don't care what Google, FB, and others do.
I just want Apple to get it right.
Who knows— when the do, others may follow suit.
Just because someone says Apple is doing it wrong doesn’t mean they are.
I'm not totally bashing the OpenID Foundation taking a stand on this. There are always struggles between proprietary implementations, derivative implementations, and by-the-book standard implementations of cross cutting technology. Standards organizations tend to be slow and plodding with few concerns about the competitive relationships that exist between members of the standards creation committee. Individual companies like to move quickly and are not only concerned about time-to-market but also beating their competitors to market and with product features. Having competitors working cooperatively on standards development is always a dicey proposition, and what's stated publicly for general consumption, e.g., "Yes of course, we at Company A fully support XYX Standard," doesn't always equate to what is happening within individual organizations who are always looking for a competitive advantage and Plan B if the standard gets too bogged down or never comes to fruition. That being said, security and privacy standards should probably be elevated as much as possible above these traditional concerns to ensure lossless and uncompromised interoperability between proprietary or derivative implementations and standards-based implementations. I'm sure Apple will engage with the OpenID Foundation at a mutually beneficial level once they demonstrate that "Sign in with Apple" has the technical chops to live up to the requirements that it must meet. Whether Apple and OpenID Foundation ever consummate their relationship with a full Kumbaya outcome that OpenID seeks is still questionable. Apple has too much riding on the (bottom) line to rely exclusively on a full stack solution that others have their fingers deeply embedded within.
They didn’t find the group FaceTime bug.
Or the High Sierra root access bug.
‘As for compatibility with generic OpenID? Nice for OpenID, but it would only muddy the waters when it comes to customers understanding what SIWA is all about. Id be surprised if Apple makes that a priority.
Being compliant with and industry standard and interoperable is also an advantage in adoption. Apple are in the unusual position of being able to force developers of thousands of apps to adopt SIWA but if they want webapp developers or other platforms to adopt it too they’ll probably have more luck if it is straight OpenID.
Compatibility with OpenID Connect matters for developers and anyone that wants to add 'Sign In With Apple' to their website. OpenID compatible means it's a tweak to configuration to add an extra OpenID provider (if the website already has OpenID integrated, e.g. has 'sign in with google') - if SIWA isn't OpenID compatible then it will require changes at the source code level, which may mean waiting for an upstream software vendor to release a version of their product that is compatible with the SIWA oddities and (depending how long it is since they last upgraded) a potentially long test / fix cycle before they can roll out SIWA support.
As an end user, I would personally prefer that Apple did everything in their power to make 'Sign in with Apple' as easy for developers to use as they can, and I think being interoperable with existing OpenID Connect libraries would help with that, especially as Apple are already using the OpenID standard.
I really really want to see app developers supporting SIWA rather than having to create new accounts, verify emails, etc, every time I install a new app that needs an account creating. (And whilst SIWA is going to be mandatory for apps that supported third party logins, it will be completely optional for apps that use their own first-party login system - it's this category of apps that have the choice of whether to adopt SIWA or not, and that choice will be a lot easier if SIWA is easy to implement for developers.)