Mobile UltimateMobile Ultimate


APPLE ISN’T ALWAYS the first company to introduce a particular product or service. But when it does finally decide to take a stab at something, it attempts to do it better than everyone else. That’s the message Apple tried to get across when it announced its new Sign In with Apple feature this month at WWDC.

During the keynote address at Apple’s annual developer conference, the company flashed onto the screen the standard login buttons from Facebook and Google—the same buttons you can use to sign into apps or websites today. They’re often presented as the simpler solution for logging into a new app; instead of going through the process of entering an email address and crafting a new password, you just use your name and password from a service you already trust.

But Apple software chief Craig Federighi warned that “your personal information sometimes get shared behind the scenes, and these logins can be used to track you.” Then he lowered the boom, revealing Apple’s answer: Sign In with Apple, the company’s own virtual login button. “We wanted to solve this, and many developers do too,” Federighi stated.

It’s true that some developers had been looking to Apple for a more private authentication option for apps—particularly as an alternative to Facebook Login, which came under intense scrutiny last fall after a massive security breach involving Login compromised as many as 90 million Facebook accounts. One security expert who spoke to me for this story suggested that elements of Apple’s authentication feature, which hasn’t launched yet, may very well be more secure than other solutions.

But other app makers have mixed feelings on what Apple has proposed. I spoke to a variety of developers who make apps for iOS and Android, one of whom asked to remain anonymous because they aren’t authorized to speak on behalf of their employer. Some are skeptical that Sign In with Apple will offer a solution dramatically different from what’s already available through Facebook or Google. Apple’s infamous opacity around new products means the app makers don’t have many answers yet as to how Apple’s sign in mechanism is going to impact their apps. And one app maker went as far as referring to Apple’s demand that its sign-in system be offered if any other sign-in systems are shown as “petty.”


As WIRED’s Lily Hay Newman wrote last week, Sign In with Apple lets you use your Apple ID account credentials to sign into non-Apple apps. Like Facebook Login and Login with Google, it aims to “centralize a group of accounts around a more secure login that you’re more likely to actively monitor and maintain, rather than a one-off account you set with a weak password.”

Apple has indicated Sign In with Apple will become available for beta testing this summer. The company has also said it will work across Apple’s platforms and the web, and that it will work in conjunction with Apple’s Face ID facial recognition feature and its Touch ID fingerprint recognition system.

Apple is using the same backend protocols for its sign-on system as others in the industry. Earlier this week, a senior developer advocate at identity management company Okta went through the early workflow for implementing Sign In with Apple and noted that Apple appears to be using industry-standard technology for the feature.

“Thankfully, Apple adopted the existing open standards OAuth 2.0 and OpenID Connect … While they don’t explicitly call out OAuth or OIDC in their documentation, they use all the same terminology and API calls,” Aaron Parecki wrote. “That means if you’re familiar with these technologies, you should have no trouble using Sign In with Apple right away!”

Chris Kanich, a security and privacy researcher who teaches in the computer science department at the University of Illinois in Chicago, agrees that “in the technical sense, this appears to be identical to what Facebook and Google are offering.”

But Apple is also adding some significant additional layers of protection. For example, within Sign In with Apple, there will be an option for Apple to create a random, anonymized email address for users. While Facebook Login no longer requires that users share an email address at all—the company says it made sharing email addresses optional five years ago—it does not offer to generate a random email address. Same with Google’s login option: It doesn’t requirean email address, but it also doesn’t offer to generate a proxy email address.

And both Facebook and Google still typically require users to share their names and profile pictures—information that is then ultimately passed on to the third-party app makers. In some cases, those login tokens allow developers to request information like birthdays, or access to calendars, as well. (Apple declined to comment on the record for this story.)


Identity Crisis

One of the elements of Sign In with Apple that has already rankled developers, though, is Apple’s mandate that app makers implement Sign In with Apple if they have already built Facebook and Google’s login features into their apps. Previously, there was documentation that suggested Apple might even require developers to position the Sign In button above all other options—but that language has since changed in Apple’s human interface guidelines. Now the requirement is simply that the Sign In button can’t be smaller than other options, and the user shouldn’t have to scroll to see it.

Leah Culver, the cofounder and chief technology officer of podcast discovery app Breaker, says she’s “not super happy about [Apple] forcing apps to use a certain type of login, and I think it’s kind of petty.”

“The question becomes, just because they control the App Store, should they control the login?” Culver says. She notes that Google doesn’t force Android developers to use Login with Google, something Google confirmed when I asked.

Buzz Andersen has been a software engineer for more than 15 years, and, having worked at Apple himself before moving on to companies like Square and Tumblr, admits to being an Apple fan. He says Sign In with Apple is long overdue, and that he personally believes Apple’s offering to be more trustworthy than other options. But even he admits that Apple’s mandate that its sign-in option is offered when other options are present could be a “non-starter” for some developers.

“I’ve already heard of people having issues with that, and it is a little heavy-handed,” Andersen says. “Apple is known for being heavy-handed with its ecosystem.”

While the option to use a randomized email address is designed to protect consumers, some developers say this could create a dilemma. Will Fischer is a product manager in the emerging technology group at Christie’s, the 253-year-old auction house. He says he’s intrigued by Sign In with Apple for his own personal iPhone use because it’s “absolutely going to make things easier,” but implementing it at work could present complications.

“It’s an interesting concept,” says Fischer. “But there’s currently no anonymous checkout in our app—as a company we have to know who we’re transacting with and who we’re selling to. It’s definitely something we would like to assess more fully.”


Basically, apps using Sign In with Apple can request personal information of the user, like an email address, but they can’t demand it. So an app that requires a more granular level of information about someone’s identity, such as an auction app or banking app, may have to simply use their own direct login. (This also means they can’t offer the sign-in options from Google or Facebook, because of Apple’s mandate.)

Not surprisingly, some Android developers also have questions around how Sign In with Apple will work for “edge cases.” Chris Maddern, cofounder and chief product officer of mobile commerce app Button, points out that many developers aren’t just building for iOS but “also for users that span iOS devices, web, and Android devices,” he writes in an email.

“This means that on both the web and Android, you’ll need to present this option somehow or risk users not being able to log in. It will be a web-based authentication flow that isn’t exactly seamless,” he says. “Long story short, 99 percent of Android developers aren’t thinking about this at all. But once the ‘Add Sign in with Apple’ requirement hits them because they’ve already had to add it on iOS, they are not going to be thrilled.”

Interestingly enough, Facebook itself—as an app developer on iOS, not as a provider of Login—still isn’t clear on whether it will have to implement Sign In with Apple within its own app. When I asked Google whether it would use Sign In with Apple for its own apps, the company initially wasn’t sure; then later said it would not, since signing into Google’s services does not involve third-party sign-in.

Sign o’ the Times

Some of the issues developers have raised may end up being resolved in the months leading up to the public launch of Apple’s sign-in feature, which is supposed to happen this fall. Other gripes may still be very real when it launches. And it might ultimately just mean that developers have to do the extra work to tailor their app around Apple’s requirements.

For example, Culver has relied on Facebook’s social graph to make it easy for people in the Breaker podcast app to connect with their friends; in the case of someone using Sign In with Apple, they’ll have to go through the added step of finding friends in the app.

But Kanich, the security researcher from the University of Illinois in Chicago, describes this as part of the ultimate tension that exists between Apple, its developer community, and its customers.

He describes Sign In with Apple as a “one-trick pony”—and that’s a good thing from a security perspective, he says. Whereas something like Facebook is a rich application that people use for lots of data sharing, Sign In with Apple is one discrete product without much of a social graph. Which means even if a hacker were able to breach it, the fallout would be limited compared to the Facebook breach.

“This goes back to the fact that Apple is going to maintain more control of your identity,” Kanich says. “And that gives Apple more control, which the third-party app makers don’t like. But the third parties aren’t the customers; the users are the customers. And that’s where that tension will really build.”