
Sign In with Apple [video] - olliej
https://developer.apple.com/videos/play/wwdc2019/706/
======
crazygringo
I don't like that it's required for developers to include if they include any
other third-party sign-in.

US competition laws are outdated with undue reliance on the concept of a
monopoly.

I don't care if you're a monopoly or a third of the market or even a small
company. If you run a marketplace or app store or similar platform, you should
NOT be able to:

\- Force usage of a separate product of yours over/with competitors (in this
case, Apple sign-in, but also Apple Pay instead of Google Pay, etc.)

\- Prevent competing products from appearing (whether Apple not allowing other
browser rendering engines, Amazon not allowing Google Home or Chromecast to be
sold, etc.)

\- Rank your own items higher in search results etc. if competitors can't bid
to do the same e.g. sponsored results for everyone including yourself (so
Amazon Basics or Google Shopping needs to be listed as a sponsored result, not
as a separate feature)

This is the kind of thing 21st-century legislation for fair competition should
address.

~~~
toomuchequate
This isnt a monopoly.

As someone who has never bought an Apple product, I can safely say their
monopolistic practices don't affect me.

Stop buying Apple products. Its that simple.

~~~
gman83
I don't buy Apple products (well not exactly true I have a MacBook but only
because I'm forced to use that to build for iOS). But for my app which uses
1st party login or Facebook as an alternative I am now forced to provide Apple
login. If Google follows suite I'll be forced to provide Google login on
Android, etc. Probably I'll just end up removing all third party login too
much of a hassle, although I'll definitely lose users.

~~~
dann0
I’m not trying to be a dick, I’m genuinely interested. Why would you make a
product for a platform you don’t support? Feels like a vegan owning a
hamburger shop.

Is it the market size that keeps you in the iOS space? Are you on other
platforms? What are the revenue/cost/effort ratios for each? Does it make
sense to focus on non-iOS options?

~~~
clarky07
probably because it's the most profitable platform. iOS easily makes more
money than Android even though it has less users. In my experience, it's not
close.

------
albertgoeswoof
The killer feature here is the anonymous email address forwarding. It shows
Apple actively ceding an opportunity for exchanging marketing data in favour
of user privacy. It does feel like Apple are taking privacy seriously and
positioning it as more than just a marketing campaign.

I am tired of seeing my email address popping up on leaks and I don't want to
rely on spam filters any more. The best spam filter out there is built into
gmail, but they are no longer interested in actually preventing spam, instead
they want to control it. Now Google shows me ads that look exactly like emails
in my inbox, inside the iOS app.

I wasn't happy with this so I built [https://idbloc.co](https://idbloc.co),
which is basically equivalent to the disposable email element of Sign in with
Apple, now that Apple built it into their Sign In, I guess now it exists for
users who don't want to or can't use Apple.

~~~
jadbox
It also gives Apple far more control over the ecosystem. By not providing 3rd
parties access to email, Apple makes themselves not only the controllers of
the physical devices and also over the full identity of their users. My
viewpoint is one of decentralization, and I don't see this move as being a
long term beneficial one.

It's not a stretch of an imagination that Apple might cut a developer out of
the app store for some abstract-defined violation of terms (as they do now)
and now ALSO cut that developer from the identity/contact with their users. In
total, this is almost the ultimate kill switch to push companies to adhere to
their policies or risk a total shutout. This scenario might be considered
overblown, if it wasn't that Apple already exercises pushy monopoly(esk)
control on their ecosystem. The new identity system expands that control to
now outside the Apple hardware ecosystem, possibly affecting platforms like
Android.

I'm ranting here a little, but I think we should be cautious of accepting
privacy as the sole reason Apple wants to enforce all app authentication to
use.

~~~
ddebernardy
> By not providing 3rd parties access to email, Apple makes themselves not
> only the controllers of the physical devices and also over the full identity
> of their users.

No they're not. They're preventing _third parties_ from accessing your data.
You can communicate with your customers just fine; it's just that if you sell
their data (or get hacked) the email you get is useless.

~~~
Someone
_”it 's just that if you sell their data (or get hacked) the email you get is
useless.”_

It’s just that _whenever Apple decides so_ , the email you got becomes
useless.

Apple is judge, jury and executioner, and it makes the laws. That _is_
problematic.

~~~
SquishyPanda23
That sounds like a great feature. I would love for the ability to make an
email address inactive after I sign up.

The percent of times I want to recieve email communication from something I
have to sign up for is very close to 0.

~~~
Nerdfest
Get your own domain through someone that has an email service that supports
aliases. Every sign up can have a different address. It's like $10 per year
and you're email is not at the mercy of whatever mega-corporation owns your
email.

~~~
buzzerbetrayed
Any suggestions on which provider to use?

~~~
wtmt
IMO, it depends on how many mailboxes and aliases you need. Providers like
Fastmail charge by the mailbox (with up to 600 aliases for each). Same with
Runbox, Mailbox.org, etc. (the number of aliases varies). Migadu provides
unlimited domains, mailboxes and aliases for a fixed price that decides how
many outgoing mails you can send everyday from all mailboxes in that account.

------
habosa
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).

~~~
olliej
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.

Alternatively:

* 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.

~~~
nahtnam
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

~~~
olliej
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.

~~~
stickfigure
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.

~~~
olliej
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?

~~~
scarface74
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”.

------
atonse
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-...](https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-
with-apple)

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

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

------
jeena
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...](https://aaronparecki.com/2019/06/04/23/sign-in-with-apple-
misunderstandings)

~~~
3JPLW
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.

[https://news.ycombinator.com/item?id=20128029](https://news.ycombinator.com/item?id=20128029)

------
olliej
Just so people can watch the detailed developer introduction.

Specifically:

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.

~~~
Reedx
> _...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.

~~~
ballenf
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.

~~~
endlessvoid94
It does significantly reduce the problem.

~~~
olliej
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.

~~~
vlozko
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.

------
ardit33
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.

~~~
kalleboo
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

------
alwillis
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…

~~~
cwills
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.

------
papa_bear
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.

~~~
dstaley
> 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?

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

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

~~~
papa_bear
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.

------
msravi
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.

~~~
lern_too_spel
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.

------
aclelland
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.

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

------
WalterSobchak
Previous discussion:
[https://news.ycombinator.com/item?id=20086045](https://news.ycombinator.com/item?id=20086045)

~~~
olliej
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.

------
simonw
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-...](https://developer.okta.com/blog/2019/06/04/what-the-heck-is-
sign-in-with-apple) is particularly good - but no one seems to have deployed a
button I can click anywhere yet.

~~~
sirn
If you’re using iOS 13,
[https://appleid.apple.com/](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).

------
dubcanada
JavaScript example
[https://developer.apple.com/documentation/signinwithapplejs/...](https://developer.apple.com/documentation/signinwithapplejs/configuring_your_webpage_for_sign_in_with_apple)

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

~~~
simonw
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](https://github.com/aaronpk/sign-in-with-apple-example)

~~~
busymom0
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?

------
rahulrav
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"](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.

~~~
jchook
> 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:

`AppleID.auth.signIn();`

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

~~~
rahulrav
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.

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

~~~
beering
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.

~~~
closetohome
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.

~~~
TimothyBJacobs
What about using a password manager?

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

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

------
marpstar
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).

~~~
mpweiher
> 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.

------
steve_taylor
> 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.

~~~
dannyw
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.

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

------
rcarmo
" * 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...](https://appleid.cdn-
apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js)

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

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

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

------
drampelt
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](https://moo.do)
stores everything in Google Drive, if they have to implement Sign in with
Apple the app won't function

~~~
olliej
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.

e.g.

* 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)

vs

* 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 :-/

------
scotchio
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.

~~~
bubblethink
>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.

~~~
olliej
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.

------
jarjoura
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.

~~~
askafriend
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).

------
ceejayoz
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.

------
martamorena
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.

------
ljm
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.

------
stefano
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?

~~~
larkost
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.

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

------
lern_too_spel
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.

------
xenospn
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.

------
stickydink
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?

~~~
MBCook
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.

------
mderazon
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?

------
paxys
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.

------
lucasverra
Tested a sample demo and working OK

[https://github.com/nov/apple_id/issues/1](https://github.com/nov/apple_id/issues/1)

------
mindgam3
Previous discussion:
[https://news.ycombinator.com/item?id=20086045](https://news.ycombinator.com/item?id=20086045)

------
dcbadacd
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.

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

~~~
dcbadacd
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.

------
MR4D
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.

------
glitchc
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?

~~~
muro
That your app gets rejected otherwise.

------
jay_kyburz
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?

------
mrfusion
So how do I benefit as a consumer?

------
PunksATawnyFill
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...

------
buboard
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.

~~~
coder543
> 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.

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

~~~
dev_tty01
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.

~~~
jaydz
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.

