OpenID Foundation Claims 'Sign In with Apple' Could Expose Users to Security and Privacy Risks

[prasand]

nowadays, you just get asked to login with an account from a list of providers, like Google or Facebook.

I’ve only started writing software that uses it this year, so my API experience is limited

Brings up a good point: Facebook dropped OpenID support awhile ago (2014). Facebook Connect is no longer compatible with OpenID. So ... Apple is just doing the same. There is little reason to be compatible with OpenID. Even large developer communities agree.

Seems you’re a bit late to the party. For Google, the ability to make as many connections to users, no matter their login method / login token, has much incentive. Otherwise, I’m sure even they would’ve dropped OpenID awhile ago. But so long as there are drunks still on the dancefloor at 6am, Google has reason to play music.

 

[Alan Wynn]

Doubtful Apple will agree to make their login system more interoperable since part of its strategic advantage is user lock-in.

In this case, interoperable, does not preclude lock-in, but encourages it. What interoperable here means is that code that supports login with OpenID Connect would also support Sign In will Apple, making a greater number of applications and services able to accept Sign In with Apple immediately. The more people are able to use Sign In with Apple, the more likely they are to be handcuffed to the ecosystem (with super comfortable, plush handcuffs).

 

[nt5672]

There are two issues here from my viewpoint.

1) Is OpenID a worthy standard?

2) Is Apple's Apple ID implementation good?

I don't think both of these can be answered at the same time, so I'll concentrate on number 2.

Apple has a horrible reputation for developing new system services (like iCloud) which is what Apple ID is. It takes Apple years to get it right. Why? Because Apple is today first and foremost a marketing company, not a technology company. The focus on marketing over technology causes Apple to rush things out to make the Keynote and the news cycles.

Apple's internal ID process for iTunes, iCloud, and devices is about the worst I have seen. They don't handle multiple accounts correctly, they don't allow sharing services correctly, and etc.

While Apple ID may be the future, I would not put any trust in it for at least 12 months from release.

The funny thing is I have secure linux logins decades old that are still secure today. Sure I have to manage them (set up and renew the keys) all myself. But the technology is old as the hills. The problem is that everyone wants to control sign in IDs. That is what OpenID is about. Having a really easy public/private key generation process with a public revocation process could end all of this complexity. But the big corps lose control that way.

 

[Krizoitz]

Because everybody necessarily uses what’s app for communicating outside the Apple ecosystem.

No, they really don’t. Visit Japan, everyone uses Line, including iOS users. Visit the Ukraine, everyone uses Viber. What’s App is one of many messaging options, dominant in some countries unheard of in others.

 

[mannyvel]

OpenID is at

1) Is OpenID a worthy standard?

OpenID tries to solve a common problem, and it works for the most part. It's not hard to implement, the standard is open, and it's well-documented.

For smaller companies it provides a secure mechanism for letting the user authorize access from service A to resources/account info on service B.

It's better than an all-or-nothing approach to access, and the service implementing OpenID needs to put some thought into what can be accessed and implementing that access. What's unknown how many users don't actually authorize all the requested claims, which would make the more granular control offered by OpenID sort of pointless.

 

[talkin73]

If you look in the document it’s all little things, like Apple not providing adequate documentation for their differences, not returning a nonce which is a standard to help protect from MITM attacks, some methods and calls are names like the openid standards but do something else, and in some cases their documentation just flat out being wrong.



Yeah, but as a dev just being able to reuse the same set of standards for Apple login as all the others makes my life easier and in general makes everyone more secure than having to hack together different code sets for every provider, more chances for me to mess up.

Did you say the same when apple required faceid in addition to touchid? “More chances for you to mess up” would best be solved by more attention to detail, rather than Apple falling in line like automatons, no?

Frankly I know little about this specific new sign in option, but if it’s different than what google and Facebook do, it has my interest. We’ve learned through a series of decisions over a relatively long period of time... apple is working moreso to protect our info, Facebook and google (in particular) are looking to profit from it. No one is making any secrets about this. Facebook has also been obscenely unable (unwilling?) to protect our data.

For me, simply being different than Facebook’s approach is, thus far, it’s most appealing quality.

 

[talkin73]

Not at all. I've already heard several Apple developers say they're concerned about the lack of interop with OpenID.

Concerned because they think apple will implement something less secure than google and Facebook? Or concerned because it requires additional coding on their part? If the former, I suggest they look to history and sleep peacefully tonight. If the latter, then I can appreciate the concern but seems less relevant to the vast majority of us who will hopefully benefit from a more secure option... again, looking to history on this one, particularly given that past behavior is generally the best predictor of future behavior.

 

[Timemaster]

Did you say the same when apple required faceid in addition to touchid? “More chances for you to mess up” would best be solved by more attention to detail, rather than Apple falling in line like automatons, no?

Frankly I know little about this specific new sign in option, but if it’s different than what google and Facebook do, it has my interest. We’ve learned through a series of decisions over a relatively long period of time... apple is working moreso to protect our info, Facebook and google (in particular) are looking to profit from it. No one is making any secrets about this. Facebook has also been obscenely unable (unwilling?) to protect our data.

For me, simply being different than Facebook’s approach is, thus far, it’s most appealing quality.

When Apple added FaceId to Touch ID the api for devs is exactly the same. The only thing is devs had to deal with is wording that is just saying the faceid or Touch ID.l but to check if valid the exact same api. It did not require changing anything in the code to support it. It did not break anything nor add a new security risk for devs to risk messing up on.

Reducing risk and places to mess things up is a good thing. It is so much easier to change a connection string but not have to risk messing with the response as the rest of the code supports that response.

 

[Alan Wynn]

Apple isn't the first to proxy email for privacy since domain name registrars have been doing it for ages with private domain registrations.

First, no one has claimed that Apple’s forwarding of email is, by itself, novel. What is novel is a system where every time one creates a new account using something like OpenID, the system offers one a chance to not provide one’s real email. Your straw man comparison is basically invalid.

Also, not comfortable with Apple MITM all the emails and have visibility into the sites and services I access plus all email visibility.

Yet in the next breath you argue for Sign in with Google, a provider that makes its money vacuuming up your data, has ignored do not track and has already said it only keeps track of where you and when you log in for a limited period vs. Apple that has does not do any of that.

Got it.

Lastly, no hardware token integration like with 'Sign in with Google' and their Titan Security Key or built into Pixel 3a.

Apple’s 2FA is sufficient for most users, and is an improvement over the same shared password on a million sites that people currently use. What is great is that Apple can upgrade its user security at any point, and all the Sign in with Apple sites just get the benefit.

 

[talkin73]

When Apple added FaceId to Touch ID the api for devs is exactly the same. The only thing is devs had to deal with is wording that is just saying the faceid or Touch ID.l but to check if valid the exact same api. It did not require changing anything in the code to support it. It did not break anything nor add a new security risk for devs to risk messing up on.

Reducing risk and places to mess things up is a good thing. It is so much easier to change a connection string but not have to risk messing with the response as the rest of the code supports that response.

As a non-dev that’s helpful to know. Thanks for sharing the specifics. Sounds like more work that is both tedious and detailed. Hopefully whatever is implemented by apple that requires this if devs is intimately a more secure and useful solution for all and, perhaps, pushes other companies to up their game.

 

[Tech198]

"However the implementation of Sign In with Apple has now been questioned by the OpenID Foundation (OIDF), a non-profit organization whose members include Google, Microsoft, PayPal, and others."

But look who makes up the team? None of them go as far as Apple with stance on privacy. Don't wanna know who these "Others" are... Probably aliens.

 

[inkswamp]

Because of the WiFi support and iMessage extensions that are only supported on Apple devices.

But you can export that content out of Messages which means it's not lock-in. Lock-in is, by definition, when a company traps you into their system with no easy way to get your stuff out and blocks attempts to do so. That's not the case with Messages. There are built-in ways to get your content out of Messages and plenty of third-party apps to do it. Don't confuse a lack of interoperability with other message systems with lock-in. It's not the same.

 

[BootsWalking]

But you can export that content out of Messages which means it's not lock-in. Lock-in is, by definition, when a company traps you into their system with no easy way to get your stuff out and blocks attempts to do so. That's not the case with Messages. There are built-in ways to get your content out of Messages and plenty of third-party apps to do it. Don't confuse a lack of interoperability with other message systems with lock-in. It's not the same.

You can export content out of Adobe's Create Suite and that is considered one of the most locked-in apps on the planet, so your definition of lock-in is different than the markets'.

 

[prismic]

Hmm. There’s a lot of misinformation here.

First of all, if you heard of OpenID, you should know that it’s long deprecated. Almost no one uses OpenID or OpenID 2 anymore. OpenID Connect is spiritually different from its predecessors (it’s basically JWT on top of OAuth2), and trust me, you’ve all used it at some point, even when not dealing with Google/Facebook/Microsoft, without privacy concerns. It and SAML are probably 2 of the most popular single-sign on solutions out there. Often times it’s all done in the background so you aren’t even aware of it.

Secondly, OpenID Connect doesn’t deal with privacy. It’s about authentication (security), how you authenticate to a third party service (for example, macrumors.com) via an identity provider (for example, google). What that identity provider and service does with your information afterwards is not a concern of OpenID Connect. So to say Apple should not follow the spec doesn’t tell you anything about how private your information is.

Third, getting an authentication service spec right is HARD. There are many, many different things to consider, and people figure out new ways to break it all the time. So to truly bullet-proof a protocol like OAuth2 takes many people working in different architectures across different scenarios to figure out all the weaknesses. While I am not the one to claim that Apple can’t do it if it devotes its resources to it, why would it want to? It would be different if OpenID Connect/OAuth2 somehow leaks privacy information, but as I said, it doesn’t deal with privacy, but security. So unless they found a critical security flaw in OpenID Connect/OAuth2 somehow (which would be very irresponsible of Apple to not report it if that’s the case), it makes the most sense to use the same spec so development teams doesn’t have to learn an entirely new spec that doesn’t offer anything new under the sun.

Finally, if you want to avoid anything Google/Facebook sponsored, you need to turn off the internet or something. Most (if not all) modern web services runs on software sponsored by Google/Facebook/Microsoft.

 

[Detrius]

Brings up a good point: Facebook dropped OpenID support awhile ago (2014). Facebook Connect is no longer compatible with OpenID. So ... Apple is just doing the same. There is little reason to be compatible with OpenID. Even large developer communities agree.

Seems you’re a bit late to the party. For Google, the ability to make as many connections to users, no matter their login method / login token, has much incentive. Otherwise, I’m sure even they would’ve dropped OpenID awhile ago. But so long as there are drunks still on the dancefloor at 6am, Google has reason to play music.

OpenID Connect was finalized in 2014. Facebook uses OAuth 2.0, which is also used by OpenID Connect, so they are compatible.

Regarding being late to the party, I’ve inherited a bunch of ASMX and WCF services that have no authentication at all. So... that’s an understatement.