Hacker News Reader

Sure, except there is no documentation for it. From the article:

"For example, Apple vaguely states that you can implement Sign in with Apple on Android, but there is no direct documentation on how to do it. We understand that Apple probably doesn’t care much for Android, but if they are going to provide a login system, and are going to force developers of multi-platform apps to adopt it, then providing no real support for a major platform that these multi-platform apps run on is not acceptable."

Apple has provided documentation, it seems like the article describes a lack of attempt at trying?

On the Getting Started [1] page it lists three options: Apple platforms [use AuthenticationServices], Unity [use the asset from the Unity Asset Store], and "Web and Other Platforms" [use Apple JS/REST]. That "Web and Other Platforms" link provides a wealth of useful documentation [2].

Tbf, the exact word "Android" is missing, but this is an elementary school-level process of elimination that maybe Android is inferred in the words "other platforms".

[1] https://developer.apple.com/sign-in-with-apple/get-started/

[2] https://developer.apple.com/documentation/sign_in_with_apple...

https://developer.apple.com/documentation/sign_in_with_apple... is more “direct” than most of the documentation I’ve seen on how to implement “OAuth” with other providers. (Trying to figure out how to integrate with “Microsoft 365” is particularly painful...)

Eventually you might realize it’s based on an open standard https://openid.net/2019/09/30/apple-successfully-implements-... and that it’s relatively similar to other such standards, except with the option to mask your email, etc.

As an geeky end user, the only way I trust these services for login is if I can link more than one, or even more than one email from the same provider. That way I know I’ll have a backup in case I lose access to the social network or email address that I signed in with... it’s annoying when I can’t add a password or set an email just because I also want to login without a password sometimes...

Wow you're not kidding that's actually surprisingly clear documentation and it should be very easy to implement.

It was way worse when I had to implement it a few months back.

It's still incomplete, their implementation deviates from the standard or use some lesser used mechanism like the form_post response_type, requiring custom code.

Implementing this was not a pleasant experience.

Also, even if they support it, it does not look like Apple has released an app or SDK for Android.

So there would be no apple account registered on the phone.

So each app wanting to implement apple login would have to :

- pretty much implement it from scratch

- still have a very subpar experience compared to any other login mechanism (even way worse than email + password) since they would have to ask users to find their obfuscated apple email address.

Sign in with Apple asks for your normal iCloud email address. It's Apple's servers that look up your app-specific obfuscated relay email address if you've used one for the app.

duh ! I blame my sleepiness for missing that.

Still pretty meh that it is the only solution of its kind without an sdk

They don’t need an SDK if they’re using protocol-compliant OpenID Connect.

Any OpenID Connect (or OAUTH2) library of the devs choice is the SDK.

The Facebook/google SDKs are simply there to add trackers and bloat.

A good sdk means that it is both quick to implement and that it can integrate with the OS account feature (meaning users only have to authentify once for their apple account)

They directly address this point. In the article they say they considered adding sign in with Apple everywhere. Besides the fact that it's more code to write and test, they say the documentation is very poor for other platforms, as it's not even great for iOS.

It seems sufficient to me?

https://developer.apple.com/documentation/sign_in_with_apple...

Absolutely not. Compare the native ios documentation[1] with their "other platforms" documentation[2]. Their native documentation has code snippets, helpful links, and explains in depth what is happening.

The "other platforms" documentation is "make this request, store some data, follow redirects". No code, no helpful links on how you might accomplish these things, nothing. You get the bare minimum.

I'm not saying its impossible, and neither is the article. I'm saying that Apple clearly doesn't care about supporting a platform as huge as Android, and that clearly signals to multi-platform developers that they are on their own.

[1] https://developer.apple.com/documentation/authenticationserv...

[2] https://developer.apple.com/documentation/sign_in_with_apple...

The nature of "other" platforms means that example code could be in any language at all.

The fact that their iOS documentation is so much better than average doesn't mean their "other platforms" documentation is inadequate. It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.

I think you're missing the point.

Part of the problem is that android is an "other platform" in the first place. Sign in with apple is supposed to be a cross platform feature, but Apple can't be bothered to even write out some decent documentation for a platform with over 2 billion devices. Compare, for example, the Google sign in for iOS[1]. They provide a working example project and full documentation.

If you are a developer supporting a cross platform app, you're not getting much help from Apple. That's what the article is saying: integrating this feature is going to be more work and more risk than it's worth. That's the point.

> It just means there's plenty of room for third parties like indie bloggers to documentation their own approaches in JavaScript, Python, Ruby, Rust, or whatever.

We are talking about signing in. This is one of the most fundamental features you need to have. This is not something that you just copy paste from some half baked blog post. It is amazing to me you think that's acceptable.

[1] https://developers.google.com/identity/sign-in/ios/start

> This is not something that you just copy paste from some half baked blog post. It is amazing to me you think that's acceptable.

Have you ever actually implemented a proper sign-in process e.g. with OIDC, JWT, SSO etc ?

Because half baked blog posts is the industry standard.

Hardly a surprise that they're so crap, then.

Not surprised the documentation that highlights the Apple Platform is better, however, give.

That said, it’s a REST API you query and you get a well defined payload:

> A successful response contains the following parameters: code A single-use authorization code that is valid for five minutes. id_token A JSON web token containing the user’s identity information. state The state contained in the Authorize URL. user A JSON string containing the data requested in the scope property. The returned data is in the following format: { "name": { "firstName": string, "lastName": string }, "email": string }

I could implement this using curl really it’s that straightforward. If you have any experience consuming REST APIs

To repeat myself, I know that this is more than possible to implement. But you're also hiding a lot of complexity about redirecting from your app to a browser, managing state, custom url schemes, etc. If you want to turn your curl request into an actual app, there's some nontrivial code you have to write and test yourself. And this code is important - if a user can't sign in, your entire app is broken.

And to what benefit? This is the point of the article. Sign in for apple is extra work and extra complexity for no benefit (to the developer, at least). It's an immature project and the fact that Apple is putting in the bare minimum effort into the docs does not encourage me to adopt this feature.

Google, in comparison, has a working sample project and step by step guide for implementing Google sign in on iOS[1]. Google sign in is just as much a "curl request" as apple sign in, but they put in the effort to give a high quality, well integrated, and native example.

Apple can't be bothered, which discourages people like OP from adopting the feature.

[1] https://developers.google.com/identity/sign-in/ios/start

And even with that - they are not going to use Google.

Even though there is way more value in supporting Google, than Apple. Google SSO is widely used in small businesses, unlike Apple ID.

I agree in principal, but in practice this isn't as easy as one would hope. Each IdP has slightly different requirements and parameters for connecting clients. There may be significant code non-overlap across providers, not to mention across platforms.

Facebook, for instance, doesn't actually implement OpenID Connect, but has a custom layer on top of OAuth. Their recommended method of connecting is a client SDK for each platform.

That’s what I was thinking as well. Why not just treat it like any other OpenID provider and show it for all platforms?

Heck, I've been happily using "Sign in with Apple" on linux anywhere I can.