Sign in with Apple and a few additional thoughts

We have recently added support for “Sign in with Apple” to our login screen and wanted to share some thoughts on our experience. In addition to “Sign in with Google and Facebook”, it enables another option for our users to create and login to an eBay account without having the need for an eBay password. Enrollment experience is a bit cumbersome as compared to Google/Facebook but the sign-in flow is certainly slick…especially if you have Identifier First.

Enrollment Flow

Sign in Flow

It’s been a challenging (and certainly a lot longer) effort to implement this (compared to Google/Facebook). As a user, I can see the privacy benefit but it makes the job of a relying party much harder. A number of issues have been raised earlier. Here are a couple of links that summarizes it well.

There are a few points that specifically stood out for us:

• Account Linking: When a user selects a Google/Facebook to login, we detect if an account with that email already exists and offer the user to link with their existing account. For relying parties like eBay with a large existing customer base, it’s a fairly common flow. ‘Hide my email’ feature of Sign-in with Apple facilitates users unintentionally creating a duplicate account. As a relying party, we can’t enforce ‘Show my email’ as default. Most e-commerce sites anyway end up asking for email/phone/shipping address in the downstream flow….and hence I’m not sure how much the privacy/anonymity argument holds true in this context.
• Customer Support: When a user is locked out (forgot password, lost phone…) or has a need to contact customer support, a human readable identifier is needed for discovery – usually an email / phone for most sites. Random, anonymized, private relay email makes that conversation much harder.
• Device Agnostic (not): User experience as well as implementation across iOS, Android and Web is different. Most sites offer services across all three channels. Not only it results in inconsistent experience, account recovery/access without your iPhone becomes a real challenge.

In addition to the above issues, I see two additional challenges. I don’t really have proposals or solutions for either of them but love to hear thoughts.

• Nascar 2.0: We have been through this once with OpenID 1.0. And back then, mobile experience wasn’t even that big a concern. This is how our login screen looks like:

I see some other promising IdPs e.g. Zenkey, BeyondIdentity, WeChat…and some great efforts from Mastercard, Santander, Capital One etc….and of course SSI; but have no real estate left. 

• Inconsistent device biometric login experience:  For any authentication method, there are at least three flows we need to address: Enrollment, Sign-in and Account recovery. Device biometric is certainly a secure and convenient way to authenticate. However, there are multiple ways to support it. You can have your app directly support it via iOS APIs. Or you can have it via WebAuthn/CTAP.  And now via ‘Sign-in with Apple’ via OIDC, which eventually leverages device biometric. Each of these three ways have a different underlying implementation (more maintenance for a relying party) and a slightly different user experience across enrollment, sign-in and recovery. It may not be a challenge for a tech-savvy user but certainly a concern for many.

As much exciting as it is to work on this, there is certainly a protocol soup and complex experiences to manage. These efforts are being primarily driven by platform vendors. Instead, they should be driven by customer support teams of relying parties. A user can login to eBay via webauthn enabled  ‘Sign in with Facebook’ with a .gmail address and a FaceID. Or just Sign-In with Apple and FaceID. Or just FaceID to eBay. This is just on iOS. There is certainly a lot of flexibility. But it also adds to complexity.

That’s how passwords win.