Hacker News new | past | comments | ask | show | jobs | submit | page 2 login
Sign In with Apple [video] (developer.apple.com)
584 points by olliej 41 days ago | hide | past | web | favorite | 440 comments

It seems like it could be really good for users, but the fact that it's _required_ for any apps that use other 3rd-party sign-in options and that it's _required_ to be listed first among those options leaves a bad taste in my mouth.

I can't even imagine what would happen if Google did the same thing with Google Sign In and the Play store.

Disclaimer: I work for Google, not on anything related, and am speaking for myself (as always).

It's not required to be first, it's "suggested" :-/

But lets look at it another way:

* I buy an app on the App Store, and then find out that I have to use FB or Google login.

* So to use the app I have purchased I am required to allow the app and/or Google or Facebook to further their abuse of my privacy.


* An App is shown as "Free"

* I install it, and it require FB or Google sign in.

That isn't free. Again, signing up for abuse of my privacy is not free.

>> That isn't free. Again, signing up for abuse of my privacy is not free.

Surely the logical extension of this is that no app with ads should be marked as "free". Your attention is not free. Right?

The Google Play Store will show "contains ads" under the install button. Same for "contains in app purchases". Makes it much easier to see which app is really free.

This is a good policy, and the Apple App Store has done the same thing for a while.

Not just the attention, but also the knowledge of where my attention is, shouldn't be free. Right?

However it is _required_ that you add Sign in With Apple. I'm all for privacy but I disagree with this move because apple said "You must add Apple Sign In" rather than "You must allow one form of anonymous login" which means they are forcing developers to use their tools.

Additionally, if the app only has FB or Google login and you don't use either, you can just not use the app

Developers wouldn’t add it if it wasn’t required, full stop. They want access to your social media presence and personal information.

The problem here is very basic:

Why should an app be listed as free if using it requires sacrificing my privacy to use it? That's fundamentally not free.

If the app cost me money then I've purchased an app I cannot use.

This is very simple: they're saying that you cannot require Apple's (and by extension your) users to submit to abuse of their privacy in order to use your app.

This "they're stealing my privacy!" outrage is tiresome. Someone built an app; it authenticates a certain way; if you don't like it, uninstall it. Both Google and Apple offer near immediate refunds. But really there's some due diligence required here - installing an app is not like visiting a web page, you should take a little care what you spend money on.

You're complaining that someone else is building apps in a way you don't like. That's their right; they aren't building them for you.

Why should Google know what apps I'm installing?

Why should Facebook?

Why should I have to get accounts for those services just to use your app?

Why should apple list apps that can't be used by users because of they require user's to create accounts with companies that are known to abuse user privacy?

The last point I think is the most reasonable: why should I, a user, be required to use some arbitrary third party just to use your app?

If you are solely using them for login support, and nothing else, then all you're doing is adding one more OAuth provider. What makes it so hard to require an Apple identity if you're already willing to accept google or facebook ones?

Besides that, I’m downloading an app from the Apple App Store. They already know which apps I’ve downloaded. They aren’t getting anymore information via “Sign in with Apple”.

Why should I build an app the way you want?

You are entitled to not use my app. I am entitled to not care.

They are complaining that these app developers are misrepresenting the cost of the "free" app. What it really costs is access to data about you as a Google/FB user. Sure, build an app like that all you want, but don't lie about it.

In the common usage of the word they are totally free. If you want to redefine the word as it's used, let's start also considering your bandwidth isn't "free" and so these apps aren't free in that sense either. How about the electricity you paid to charge your phone? The calories you ingested that help you operate the phone?

The common and almost universally accepted understanding of "free" is "no exchange of money". Saying those who don't adopt an extreme viewpoint are lying is dishonest.

The common usage of the word "free" is something like "without cost" (yours doesn't work and I actually couldn't find a definition that explicitly says "money"). Placing ads in an app has various costs, just not usually monetary. I don't think you need to redefine anything or go to this odd extreme you're trying to straw-man into the argument.

"There's no such thing as a free lunch" agrees with you - things described as free often have some cost, even if not monetary

Does Apple have a feature in their app store that allows developers to mark their apps as "Monetarily free but you have to sign in with Google"? If not, how exactly do you expect developers to comply with your demands when Apple provides no way to do so?

Your "they're stealing my emails!" outrage is hard to sympathize with.

If they are developing for iOS, they are already “forced to use Apple’s tools”.

Sure, but would you agree that open source tools and being able to choose the tools we want is better? We should have that same freedom when it comes to building authentication into our applications

It’s standard OATH. There are libraries for every language that I’m aware of that let you integrate with OATH providers. You don’t have to use Apple’s tools to do it. You could use “sign in with Apple” from any platform.

But what good would “open source tools” do overall if you still have to integrate with Apple’s services/APIs to do anything useful - the same is true with Android/Google Play Services.

Reading and replying to this comment was not free then.....

Free in the colloquial sense means "no money required", otherwise nothing is free since there is always some cost, if not an opportunity cost. What are you going to do, complain that an app required bandwidth to download?

"Suggested" by virtue of being part of the HIG. I and I'm sure many others have experienced app review rejections by virtue of HIG violations.

I can kind of see your point regarding paid apps, but for free apps, you aren't really losing anything, besides maybe a few seconds of your time. If you don't like the authentication options the app offers, you can just uninstall it, and for 99% of the apps in the app store there's multiple alternatives that will offer a different set of options.

Unless I don’t have a google or fb account, in which case having an app listed in the store that I can’t use is hostile - and I bet it would be even more problematic if they elevated the rank of apps that supported Apple sign in over those that didn’t, even if it did reflect the value proposition for the user

Why are you then purchasing installing the app if you think they invade your privacy. Just dont use those apps.

I think that's pretty well established that free means free with ads.

Ok, so add a "Sign In with Apple" icon to the App Store page.

I think that if "downloading apps users can't log into wastes their time" was the problem Apple was trying to solve, this would be a good (maybe better?) solution.

But the problem they're going after is bigger: how do you allow users to keep using their favorite apps (because most people aren't super privacy-conscious) while at the same time making sure those apps don't track users or sell their data? And, like it or not (and many people won't), I think forcing developers' hand is the only real way to make this happen.

I know what you're saying but I'm okay with it. In this case Apple chose users over developers. iOS developers have to do a little more work (Apple has made it very easy from what I've seen of the framework) and have a little less freedom but users signing in to apps using 3rd party auth are guaranteed the privacy protections Apple is promising. They drew a line in the sand by making their solution mandatory but I think they had to to deliver what they're promising to users (which I think is great).

That privacy seems a bit overboard though. This is fine if a user can create his account directly inside the app. But it's not very clear how to support a workflow where you have an organization with multiple users authorized by an admin to use the app. How can the admin add a user to his organization, if he doesn't know in advance the user randomly generated email? I guess you could send an invitation code, and let the user enter that code after the apple sign in, to associate the account to the authorized user. This sounds more complex for the user than a workflow where the admin can directly authorize specific emails.

Does this apply to enterprise apps distributed outside the normal App Store? I bet it doesn’t.

Also I think you’re given the choice of using your real email address instead if the anonymizes one. At least that was my understanding.

App Store guidelines have no bearing on enterprise apps.

The randomly generated email is a user choice, they can also provide their real email. The randomly generated one would not work for things like slack sso etc.

Apple knows that for most people (unlike this website's audience), the privacy concern is not as important as using That Cool New App, and if this was just another option developers could, but didn't have to implement, many apps would choose not to -- and most people would still download them. The only way to make sure that most users' email/login/usage isn't being sold or used to track them is to force developers to offer Apple's auth option, and make it as easy to use as choosing to log in with Facebook or Google.

> I can't even imagine what would happen if Google did the same thing with Google Sign In and the Play store.

If Apple made its money by mining its users' data, there would be a big uproar about this announcement, too. But Apple made it very clear that they will not be doing that with this data, and is moving more and more towards establishing itself as the privacy-focused alternative to Google... So this is by and large (and obviously there are many people with reservations, whether about Apple forcing developers' hands, or about trusting a big company in general) being seen as more of a Good Thing.

Google should just add a similar requirement in response. With this rule Apple is forcing their signup method to be taken up across all platforms (web, Android, iOS) because you can't only enable logging in with Apple on one platform.

If Google were to implement the same requirement, any cross platform app with Apple's login would also now have a Log in with Google button, making sure that Apple won't be getting any Oauth monopoly any time soon just to keep them in check.

I am very uneasy with this as well.

Apple has just leveraged their position as the iOS gatekeepers in order to obtain a huge marketshare of the SSO market.

The SSO "market" is only a market if the SSO providers are monetizing your data at the expense of your privacy. Private authentication is not a "market" almost any of us needs or wants, but rather a right that we deserve.

Not sure why you've put "market" in quotes there. Okta is literally a SSOaaS that has a $14 billion market cap.

Does anyone use Okta outside of the Enterprise? No enterprise focused app is going to allow any random third party credentials. Okta is also not by any definition a “social network”.

It's also a "market" if you happen to run one of the largest payment networks in the world (Apple Pay) and if having users signed in with your service gives you the ability to let them easily provide payment information through you to the exclusion of your competitors (Amazon Pay, Google Pay, etc).

Apple Pay is a feature of the iOS SDK and Safari browser, not a feature of the login system. Which method you used to login doesn't change the friction of paying with it.

But it easily could in the future.

My understanding is that putting SIWA first is in their Human Interface Guidelines, which (nominally) are not mandatory. Some apps have been rejected for HIG violations, however, so maybe they'd enforce that (but I doubt it). Plenty of HIG-violating apps make it into the App Store, so they definitely don't enforce all HIG violations.

To me this is a fair rule and benefetial for the end users, it will give more options to them. It simply says "if there are competitors, you must include us".

I'm not an Apple user, but I would expect Apple to provide and guarantee that you can log in any app with your Apple login. Seems fair to me.

Also, I'm pretty confident that Google offering a privacy-oriented SSO on Google Play would be appreciated by everyone. Privacy on Android is such a joke : any app can freely read the accounts present on your phone, they don't even need you to sign in to identify you

Well, maybe if Google didn’t do stuff like trick users into installing privacy invasive apps by using developer certificates that were only suppose to be used for internal apps you might have a leg to stand on....

Can you point to anyone who was tricked? I signed up for that program myself. It was very clear what I had signed up for. I wasn't tricked into it any more than a Nielsen family is tricked into getting paid to use a Nielsen box.

You’re comparing a Neilson box with installing spyware on your phone that can intercept every piece of information you send across the internet?

Not to mention that Google knew that the certificates were meant for internal use only and agreed to the terms.

> that can intercept every piece of information you send across the internet?

Just like a Nielsen box, the app collected clearly specified data, and users were paid for it.

From the link you posted it wasn’t clear that it could intercept anything. Can a Neilson box intercept my emails? My account details and drain my account?

> From the link you posted it wasn’t clear that it could intercept anything.

That's Apple's fault if the permission screen didn't show that. What the app actually collected was different from what it had OS permission to collect and was clearly described to the user.

The whole idea of a development certificate is that it is suppose to be used for internal use where a corporation can deploy an app to employees that can do all sort of weirdness.

And employees should also be informed, just like Android informs them.

I'm thrilled about implementing this on our app so we can make registration and login even more smooth without having to be in bed with Google and Facebook. Can't wait to implement it.

I'm even more thrilled to see, that according to the Okta article linked in another thread by simonw [1], Apple uses OAuth and OpenID Connect for this, and not some home-grown protocol.

Great news all-round.

[1] https://developer.okta.com/blog/2019/06/04/what-the-heck-is-...

Hoping for a cordova plugin sooner rather than later, for us Hybrid App developers.


I'm not really sure what you're ranting about. Are you under the impression that I'm implying third party identity federation is something new? Because I'm not.

I'm implying that, it's great that we have an additional identity provider who isn't a drug addict about user data like google and facebook are, that's run by a company who has shown a history of actually caring about user privacy. It gives those of us that are concerned about privacy, an option to use for identity federation.

And I'm saying the opposite, that it's great that Apple's using an existing standard (which implies they didn't invent it) instead of doing something totally custom.

It sounds like you had that post already written and ready based on this being an apple post.

Well it seems you were more thrilled to use it instead of Google or Facebook. You could have already used gitlab or some other privacy oriented service already. So yeah what parent said seems true.

Use “sign in with GitLab” as a login for a consumer app? Are you really suggesting that?

How many non developers have GitLab accounts? He’ll, how many DEVELOPERS have GitLab accounts?

That’s like saying “you should’ve put Sign In With AutoParts Warehouse” in a site about taking puppy pictures. Who the hell is GitLab? (Is what 99.9% of people would say)

Hang on, let me count all the times I've seen an option to sign in to a third party service with my gitlab account.

How many people have Gitlab accounts compared to people with Apple accounts? Gitlab isn't even a blip on the chart in comparison.

Apple will soon have an install base of a billion.

That is why even if it were identical to a Github solution (is it ?) it is still a very big deal for privacy.

This is one of the dumbest thing I've read this week.

Even better, this may eliminate passwords. This is only available on iOS and requires FaceID / T2 chip.

Sign In with Apple will work on any device, not just those with FaceID or the T2 chip.

> This is only available on iOS

It is also available on the web (including on Android and Windows)

Aaron Parecki, the author of the "OAuth 2.0 Simplified" book, wrote a blog post on the misunderstandings around Sign in with Apple: https://aaronparecki.com/2019/06/04/23/sign-in-with-apple-mi...

That article seems worthy of discussion on its own. I submitted it (expecting to find an existing discussion) but it turns out it hadn't been submitted yet.


CAUTION: There's a redirect loop bug when you open this link in Safari. Seems to be an error in their JS. The only option is to close the tab. Works fine in Firefox and Chrome.

Just so people can watch the detailed developer introduction.


It verifies the "realness" of the account, so everyone claiming that they need user's real email address for "fraud detection" can't argue that nonsense anymore. We all know that argument was just a cover for "we want to be able to spam our users with impunity", but this specifically addresses that argument just to be sure.

> ...can't argue that nonsense anymore. We all know that argument was just a cover for "we want to be able to spam our users with impunity"

Run a site that allows/displays user submitted content and you'll likely change your mind about that being a cover or bogus argument.

But requiring an email hardly solves that problem.

And very few apps (at least of what I use) that have 3rd party auth have features where user content is displayed to others.

It does significantly reduce the problem.

How? Is it because you have "proof" that it's a real user?

If you watch the presentation or read the transcript, you'll hear that they already do a bunch of fraud prevention. I'm going to go out on a limb and say Apple is doing much more anti-fraud/fake account work that most others are able to.

I’d imagine there’s a lot of criteria being used. Maybe something like the age of the account, how often it’s used, of it was created from an often used IP address. Whatever it is, it’s probably not in Apple’s interest to disclose it.

You can still ban the underlying iOS account, you just don't get an email address to spam/sell.

Sorry what exactly does having a cloaking address do that makes this a problem?

You get an email address you can contact them through.

Then say that: "we want your email in case there are issues with your content".

But that doesn’t explain why they need your actual email.

The only reason they want a user’s real address is because they want an address the user cant stop them from spamming.

There is literally no other reason.

> The only reason they want a user’s real address is because they want an address the user cant stop them from spamming.

Unsubscribe and report to spam doesn't exist in our world, anymore?

Unsubscribe relies on the sender honouring your choice.

Deleting the anonymous redirect address they’ve been given requires no such cooperation.

Just because an account is real doesn't mean it isn't spam. Most of the forum registration spam is done by real people.

Also, I think most users anyway use a secondary or "throwaway" mail account to sign up to various websites that are not critical to them. This problem is largely already solved.

But what does getting a real email address do in that case?

If you watch the presentation or read the transcript, they explicitly say that they're doing fraud/spam account prevention.

Do you really think you're doing more fraud/spam detection and prevention work than apple?

The email is not the relevant part. Apple sign in requires the purchase of an apple device so it's almost guaranteed to not be a bot. However apple cant know (and shouldn't know btw) if the iphone user uses it to sign up and spam various websites.

Apple already has a lot of anti-spam/fraud accounts because they need to prevent iMessage spam (is your forum going to be subject to the same spam account pressure of a system like iMessage or iCloud?)

But also any argument that the makes spam harder to block also applies to Facebook or google logins - I can’t imagine spammers are using real email addresses with those services.

The only people this changes the experience for are actual users. Spammers already have a huge array of options to get “real email addresses”.

ugh, this totally vendor lock-in .

1. If my app is both in IOS and Android, and maybe Windows, would this work across platforms? The answer looks like no... Apple's definition of "multiplatform" means iOS, TVOS and WatchOS, and some javascript for the web. (given Apple's poor track record for anything web-based, good luck with that). If you want to port your app to Android or Native Windows, good luck with that. Your users are locked in.

2. If I have an app that is a competitor to Facebook, and FB decides to cut me off, I can use the existing emails so the user are not locked out the app (i.e. they will be sent an email with a link to create a password and keep their account).

This looks impossible with the apple sign in. Basically if Apple decides to cut you off, your user's accounts are lost.

No matter what some folks believe that 'everything social is evil', some applications providers provide the social log-in just because the user that prefer using them over entering the same information over and over. Instead of entering email, authorizing/verifying it, and having a profile picture, a social log-in provides those for you.

As I am building an app that has the social login (Google and Facebook) as well as simple email sign in, this feels like an additional burden that I'd prefer not to (for the two main reasons above).

Feels very anti-competitive.... Apple should provide the log-in as an option, and compete with its own merits, but not force app makers to use it.

Also, I think apple is being totally evil now: By forcing companies like Spotify and other competitors to use their log in, they are creating an very intrusive/invasive way to monitor their competitors.

Eg. Netflix and Spotify and a myriad of other Apple's direct competitor are forced to be locked in the Apple's vendor sign in trap.

As for 1, just use a webview? That's how the iOS SDKs for Facebook/Twitter worked for the longest time.

edit: Also it looks like it's just OAuth and you could implement it directly

They actually stated that it supports iOS, Android and Web.

You can use the REST API if you don’t want to use the JavaScript SDK.

This seems to be a case of “anyone but Apple” logic by naysayers.

If Mozilla or name your blessed organization of choice came up with this system, most of them would be fine with it.

But because it’s Apple, there’s all this consternation about it.

Apple’s huge advantage: their revenue comes from devices and services, not advertising.

It would be different if this was a one-off but they’ve been implementing privacy features for several years…

Not because it’s Apple, but rather because Apple are exploiting their position as iOS App Store gatekeepers to require developers to add Sign In With Apple. Mozilla don’t have this position / power.

I think people would have the same issue if Google required ‘Sign In With Google’ in play store apps that have Facebook login, and returned throwaway / proxies email addresses.

I haven’t seen anyone upset over the feature set. The only complaints I’ve seen are those uneasy with Apple’s forceful hand. They are both the gatekeeper to the store and now gatekeeper to the login. This is happening at the same time they are being investigated for anti-trust.

> they’ve been implementing privacy features for several years…

Yet this one is not a pro-privacy feature, it's an "apple owns your privacy" feature. Apple will control your account access and even be able to read your emails. Sure you trust them, but in the future they 'll use it to push their own ecosystem (like apple payments) to developers. We 've had single sign-ons for too many years to know that any ecosystem lock-in is a bad thing. As bad as email sounds, it's still the free-est , most decentralized login provider available.

> If Mozilla or name your blessed organization of choice came up with this system, most of them would be fine with it.

Mozilla came up with Persona, which would be great if they pushed it further and perhapps provided an anonymous email relayer like this instead of being based on existing email providers. With Mozilla the big advantage is that your account is not tied to any other service, real name, credit card etc. I wouldn't use Apple Login to sign up to a porn site, despite the high standards of apple's security.

Does anyone else dislike when websites offer a lot of 3rd party sign-in options? Maybe it's just me, but when there's more than one option, I often forget which one I used and it ends up being a process of checking all of them. The service I run only offers email and Facebook, and now I'll have to either remove Facebook, or add both Google and Apple (I can't just add Apple because it'll look annoying for our Android users if there's Apple and no Google).

Also, when OAUTH uses the real email address, it makes it simple to switch between the different login options without much friction, which won't work anymore for people using Apple ID. Maybe I'll just have to make it a habit to use only Apple when available, and plain email otherwise.

I had this problem two or three times and that - and the fact that some of those got removed after a couple of years like mozillas persona and OpenID - made me go back and always use email, which has the added value that I don't expose the usage of that website to a 3rd party.

> can't just add Apple because it'll look annoying for our Android users if there's Apple and no Google

just like it looks annoying for your Android users that there's Facebook but no Google?

Facebook is not related to Android or iOS. But Google is related to Android and Apple is related to iOS.

Right, my point is that it's already weird to have Facebook but not Google on Android.

I agree it's a little weird, and we do get requests for it once a month or so. When we decided on just adding a single 3rd party option, FB seemed like the most platform agnostic. We'll probably be adding all of them now though.

Yahoo has had disposable email for a long time. You can create upto 500 disposable email addresses (by going to Settings->More Settings->Mailboxes).

Also, you can give this email address a base name that is different from your normal email address so if your normal address is xyz@yahoo.com, you can have "abc" as the base name of your disposable addresses, and your disposable emails will have addresses of the form abc-<your-chosen-disposable-id>@yahoo.com (abc-spamsite1@yahoo.com for example).

So unlike gmail's "plus" email addresses, it's not possible to decipher your real email id from the disposable one. Very handy.

Combine this with Firefox's ability to remember userid/passwords and sync across devices, and you have a powerful privacy toolset that is not a pain to use and is not controlled by any single entity.

I create unique email addresses per service. The pain is in autocompleting email inputs in signup forms. It will suggest a bunch of email addresses that I used on other services and not a new one to use for this service.

I'd love if someone could explain if the 'fake email' address that the developer gets from Apple will be the same across all apps from the same developer? Or is there some way for the developer to link a login on one app to the same user on another app from the same developer?

I'm all in favour of increasing user privacy and the general direction that Apple is moving but we've got multiple Apps which allow users to log in via Game Centre, Facebook or Twitch to the same account. This allows them to access their friends, messages and support tickets from any of our Apps. We're able to do this because each of those providers gives us a unique identifier for each user (we only store that id and don't ever store the email address from them). I fear that Apple are going to make this impossible for us to do this going forward which would be a negative experience for our users.

In the presentation they talk about how the authorisation returns a stable, team-scoped (that means same developer) id.

The previous discussion was the announcement not the developer presentation that actually goes over the full details.

That conversation has a lot of people arguing about things that this video addresses.

Has anyone seen a live online demo of "Sign in with Apple" anywhere on the internet?

I've seen a few tutorials - https://developer.okta.com/blog/2019/06/04/what-the-heck-is-... is particularly good - but no one seems to have deployed a button I can click anywhere yet.

If you’re using iOS 13, https://appleid.apple.com/ now use Sign in with Apple, although obviously there’s no granting flow (where you can choose whether to give them the real email).

Can you do oauth? I'm not gonna add a random script hosted by apple to my page.

Yes you can - here's some example code that uses an OAuth redirect rather than Apple's JavaScript: https://github.com/aaronpk/sign-in-with-apple-example

This is amazing. Am I right to conclude that this lets us use it in apps older than iOS 13 as well as it’s based off of oauth redirect?

You can, and you can also read source of that file to know what that "random script" does.

That's good then. My point was more "random sdk/library", rather than script, sorry.

Unfortunately, Apple Sign In for the Web - insists on using HTTP POST's for the redirect_uri. This is a snippet from their official JavaScript library.

const t = { baseURI: "https://appleid.apple.com", path: "/auth/authorize", originURI: "", env: "prod", uxMode: "redirect", responseType: "code id_token", responseMode: "form_post", client: { clientId: "", scope: "", redirectURI: "", state: "" } };

Notice the responseMode which is set to form_post which I believe is the only supported mode.

This means you can no longer do things like localhost redirect_uri's for testing, or even use Apple Sign In on an internal web-app. Also, goes against OAuth2. :(

I submitted this feedback. Hopefully, someone takes a look.

> This means you can no longer do things like localhost redirect_uri's for testing, or even use Apple Sign In on an internal web-app.

Seems this might provide some security benefit, e.g. no credentials showing up in web server access logs. Either way, are you sure the final POST isn't made by the client? If so, the client would resolve the address. On their JS configuration page[1], I don't see any obvious evidence that Apple will make the post. They show this line:


P.S. Aghghgh the mixed camelCase and under_score makes me cringe.

  [1] https://developer.apple.com/documentation/signinwithapplejs/configuring_your_webpage_for_sign_in_with_apple

They already don’t show up if you use fragment URIs. The real issue I have is that the OAuth2 spec covers all this and we don’t have to rehash this every time a new IDP creates an Auth system.

No. The final post is not made by the client and a server has to handle the request. Webapps cannot handle POST requests from an Authorization server.

Will "Sign in with Apple" be available on non Apple devices? If not how will cross device syncing etc work?

In the presentation they mentioned that it's available for JavaScript, and said that's the way to do Sign in with Apple on web and Android.

Seems like it would be less useful on a non-Apple device though. I don't know about you but my Apple login is a nightmarishly long password and 2FA. Authenticating through FaceID or TouchID is what makes it usable.

What about using a password manager?

Good point. I have an irrational paranoia putting really vital stuff in those, but it would work.

This type of issue is why I use LastPass, and not Apples Password manager. I'm very weary of how this would work on a non-mac device and I definitely use multiple non-mac devices regularly through a given day or week.

Microsoft has a better decentralized approach https://www.microsoft.com/en-us/security/technology/own-your.... Things have come full circle.

My team has been wondering: We allow third-party login via one OAuth provider (Esri) in addition to "local" accounts. Users who log in with Esri do so to access content in their Esri account, not as a matter of convenience.

Apple's guidelines stipulate that it will be "required as an option for users in apps that support third-party sign-in".

In contrast with social logins, you cannot create an account with our app via the Esri login, and your Esri account must be set up first in the back-end to even use it at all.

We can't think of a way to feasibly support this per their requirements, unless Esri allows it via their OAuth flow as well (they do support Facebook/Google today).

> Users who log in with Esri do so to access content in their Esri account, not as a matter of convenience.

So this is not a third-party sign in. This is access to third party data which requires signing in with them.

> It will be required as an option for users in apps that support third-party sign-in when it is commercially available later this year.

This is absolutely ridiculous. What about games that allow you to sign in with Facebook specifically for the purpose of tracking your progress relative to your friends? Sign in with Apple has precisely zero purpose in this scenario.

I can sort of understand making this a requirement if sign in is required to use the app at all. I really hope that exemptions will be allowed where Sign in with Apple is 100% pointless.

If sign in with Facebook is optional and for providing specific features, then its not really using Facebook as an account management system - it’s more connecting to Facebook - so I think you’ll be fine.

The updated guidelines say nothing about the login being required vs. optional.

" * You may only use the Sign In with Apple software if you are enrolled in the Apple Developer Program."

This taken directly from their JS at https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid...

This seems to imply that using this for your personal site, for instance, requires the $99 "developer tax"...

Will Apple be able to read all the emails that are sent to/via the forwarding address?

Yes, unless services are sending encrypted e-mails to their users via keys that are established out-of-band.

Technically they could. According to the docs, they destroy the email after delivery.

How will the mandatory implementation of this affect apps that rely on a third party as the data storage system? For example https://moo.do stores everything in Google Drive, if they have to implement Sign in with Apple the app won't function

My interpretation is that the rule applies to using a third party service to create the identity you use for your own service, vs. actually logging into the service.


* You have a forum that needs a per user identity, but you recognize that managing account login information securely is challenging, and the most cost effective solution is to offload on a separate authentication service (Google, Facebook, etc)


* You're a 3rd party mail client for gmail, and you app is actually signing into the third party service itself.

Of course I'm sure all of this will be clearly and unambiguously explained by release :-/

What I REALLY want is simpler 2 factor auth.

Love iMessage autofill on text inputs from text message codes

But... Authy (arguably more secure) is super annoying to open, click, copy, re-window over, click, and then finally paste.

Would be cool if this somehow cleaned up the whole process.

Check out 1Password for 2FA management. It's extremely well done. When it auto-fills your user/password, it also puts your 2FA code into your clipboard so you can just paste it in on the next page.

Alternatively, and if the form supports it, you can use the share sheet on iOS to get 2FA auto fill from 1Password.

>Authy (arguably more secure)

What's the argument ?

>Would be cool if this somehow cleaned up the whole process.

Everyone, just leave 2FA alone. No sms. No custom garbage that sends a push from a cloud and uses a blob on the device. Use TOTP. It's simple and easy. If you want fancier phishing protection, optionally add the newer fido2 or whatever the newer standards end up being. Just no custom garbage.

For regular users TOTP isn't simple:

* you have to install an app, but you can't tell which app you're meant to use

* you have to configure the app with whatever your signin service is

* If you ever delete the app (something that is generally not harmful) you lose the ability to sign in, and reinstalling frequently does not bring back your old authorizations.

But yeah, SMS 2fa is garbage from a security stand point (and will remain so until carriers can be held liable for costs from transferring your number without your authorization), but it is usable and is leaps and bounds better than nothing at all, which is what users will do if you make 2fa hard to set up.

Little beyond me on why It’s considered more secure. Just what I read a while ago.

I just want cleaner integration for the user. Don’t care about messing with it

Yubikeys are great, but perhaps out of scope of this discussion.

It's quite amazing that Apple is doing this at the exact time the government is investigating them for anti-trust violations.

Essentially what Apple is doing is creating a new gate as they've done before with forcing developers to use their payment processing system for digital goods that costs 30% of the total fee.

Facebook Login already supports users blocking sending sites their email, as I disable that all the time. They even have published guidelines with what a site should do when they think they need that piece of information. So I'm not sold on the privacy story here. Go on, give it a try the next time you are signing in for the first time. You can even go back and remove your email permission from the security page in FB.

Apple did do one thing though, they created a bigger market for junk email services and made it easy to send those to services you expect to get notifications from. Still, this is something Apple could have built into iOS just like they did with password managers. It's not a feature that needed to be forced on anyone for any reason. As a user of the device, I can just pick, get me a junk email and presto, it's done.

I get it though, I can imagine the scenario last year right after news broke with Cambridge Analytica. This was enabled from a shady 3rd party developer using FB single sign-on and execs at Apple were pissed. They probably hastily demanded someone at Apple create something to circumvent FB's position. However, this doesn't just affect FB, it affects Twitter, Google, GitHub, Microsoft as well.

Yes Apple has good-will in this community, and its to their competitive advantage that they continue to build out more privacy focused features. However, I still do not appreciate that Apple gets the final say. This should have been a bigger conversation across the entire industry. Why didn't Apple come out and say, we are investing in the Oauth organization and then published papers on best practices? It would have been a much bigger win to get Microsoft or Google on board from the start and launched together. Hundreds of researchers all over the world would have jumped on it. Instead now we're left with another moral authority move, shoved in developers faces at the whims of Apple Execs.

I don't see how this is an anti-trust issue at all. I don't get why people keep bringing it up.

Developers are free not to implement social login. If they do implement social login then this provides a unique user benefit (privacy) while also increasing user choice (users are still free to login how they want).

Wow, 11 years too late, it's finally here. The new ingenious invention, by Apple, to let me sign in to apps with the account I am already logged in on my device. But hey, it's Apple, let's cheer...

WOW what a great feature, you have have done it again Apple. Keep the innovations coming!! :DDD

And apparently, to make up for the 11 year delay in developing this feature, they now force everyone to show it alongside of Google & Facebook sign-in.

There's confirmation in the PDF that there's a JavaScript SDK, which is nice. Native widget in Safari, but it looks like a fairly standard OAuth flow in others.

Ideal world: Apple implements this feature the way they did to test the water. With a successful result we have open source tech to mask email addresses.

How does authorization (as opposed to authentication) work with apple sign in? With Google sign in you get an actual email that can be pre-authorized on the server. With this, the server only has a phony email to work with, so how can you match that phony email to authorized users?

In this sort of login authorization is considered the severs responsibility, and in most cases that use it it amounts to: you get access to you stuff. This only handles authentication. If you need managed authorization, you are going to have to handle that yourself.

IIRC users have the option to share their real email or not.

if its not open source, I can't trust even Apple.

Google's and Microsoft's sign in PMs should be ashamed they hadn't implemented this already. Giving a stable email to all services leaks valuable information that would be more lucrative for them to keep to themselves.

I'm currently using Firebase Auth to manage my logins; Wonder if I'll have to add on another authentication layer on top of it now to add this. Don't see Google adding native support for Apple Auth any time soon.

What happens if an app has iOS, web and Android versions ? Do they all have to implement apple log in now just because the iOS app needs to implement it and they want users to be able to use the app across platforms?

Is there any word on when this is going to be enforced as a requirement (assuming you already have FB/Google etc.)?

Is it implied that as soon as iOS 13 goes out we'll start getting app updates rejected unless this is integrated?

I would expect soon after, so some people have time to update. Maybe day one. But it didn’t sound like it would be long.

I really hope this is the first step to them adding scopes for accessing iCloud data (mail, calendar, notes, reminders, photos, others). Being able to write better apps for them on Android & web would be amazing.

Tested a sample demo and working OK


Unless this becomes open for everyone, even for web devs that do not specifically have an Apple device and Apple Developer Licence, I do not see it getting far.

There's a JavaScript version that doesn't require you to have anything Apple related.

Can you please cite where it says that? OAuth requires API keys, I don't see how you could get those without anything Apple-related.

When “@privaterelay.appleid.com” starts showing up in lists like haveibeenpwnd, you know you made the right choice.

If for no other reason, this is a great reason to use it.

What’s the incentive for vendors to participate? Why would they switch to a less-featured product from ones that exposes all manner of user analytics?

That your app gets rejected otherwise.

The incentive is that the vendor will not be allowed to publish new app updates if they fail to participate.

So, you can sign in with apple, but the app can then ask for a real email address as well if they wanted to right?

So how do I benefit as a consumer?

This is a classic Apple workaround to a problem THEY perpetuate.

Apple suddenly decided on the amateur-hour policy of forcing users to use an E-mail address as their user ID. And more recently they've doubled down on that stupidity by requiring that it be a WORKING E-mail address, giving you no way to specify (in your user profile) a real E-mail address at which you can be contacted.

The public at large isn't all that savvy about how this works; so when asked to set up an account with their E-mail address and password, what percentage would you guess assumes that they have to use the same password as their actual E-mail account?

I'm guessing that percentage is very high, maybe 50%.

When sites implement this asinine policy, they become responsible not just for the user's security on that one site, but the security of the user's E-mail account. Talk about a ripe opportunity for identity theft or more, if the site's database is hacked or stolen.

You don't see banks or brokerage houses forcing people to log in with an E-mail address. Apple's ignorance of online services continues...

People are very enthusiastic about this but this is actually not going to gain a lot of traction because

- it's more difficult to implement than FB sign in and websites don't get any of the benefits

- it works with apple devices, and it will be a nightmare to use in other devices, esp. if the user uses the private email

- Apple would control and route the emails of the user and the app! This is a big privacy hole imho.

- Apple drops users or apps without second thoughts from their ecosystem, and the web is not used to this (and is not going to change)

- Maintaining new sign options is already a hassle, adding a new one that will only be accessible to a relatively small user base, with a number of hoops makes it seem less worth it.

On the plus side though, you do know that users coming from apple sign in are probably richer and better monetizable.

> but this is actually not going to gain a lot of traction

You're forgetting the part where Apple is going to mandate that app developers must offer Sign In With Apple if the app offers any social logins like Facebook or Twitter, and that the Sign In With Apple option is strongly suggested to be the first one on the list.

It absolutely will gain traction.

I think the more likely scenario will be apps removing social logins and implementing their own login logic.

Huh? Add a handful of lines of code in your iOS/Mac app to add another login button or implement a whole server based authentication scheme? Maintain and keep secure the server based authentication for the lifetime of your app? That is not at all likely given the relative cost in money and time between the two choices.

A real email address is too important for businesses. Maybe indies or really small teams will use Apple sign in, but I doubt VC funded apps will.

it will never be more popular than fb because they don't have the user base. And this only applies for new signups, generally there is no option to switch from fb sign in -> apple sign in.

- it's more difficult to implement than FB sign in and websites don't get any of the benefits

It's standard OATH just like FB

- Apple drops users or apps without second thoughts from their ecosystem, and the web is not used to this (and is not going to change)

That's no more of an issue than if you are using any other IDP that could also drop you.

Maintaining new sign options is already a hassle, adding a new one that will only be accessible to a relatively small user base, with a number of hoops makes it seem less worth it.

iOS users are a small user base?

> It's standard OATH just like FB

Doesn't it require an active developer subscription?

> That's no more of an issue than if you are using any other IDP

Google and FB are pretty lenient about who is allowed to use their sign in and i haven't heard of any horror stories. Comparatively apple is very aggressive in removing apps.

> iOS users are a small user base?

It's like 12-25% of users which is not a lot and it is very highly overlapping with people having FB/google accounts already, so it definitely seems like an "optional" sign in option.

You’re not selling an app worldwide. In the affluent countries: http://gs.statcounter.com/os-market-share/mobile/worldwide

-United States 54%

-United Kingdom 49%


- Japan 70%


-Australia 56%

Even if you take into consideration poorer countries, the more affluent population still has iOS devices.

> and websites don't get any of the benefits

What kind of benefits FB offers for websites?

A real email address they can spam? :D

You have to get the user's permission to get their email address. FB sign in allows you to access the entire FB graph api (with permissions)

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact