Security Flaw: Sign In With Apple

What is Sign in With Apple?

You might have seen a lot of websites and mobile apps that allow you to “Sign in/Log in via” Google, Facebook or Twitter. “Sign in with Apple” is an addition to the same set of authentication providers. In this approach a user need not create an account on every individual website. Rather they can simply use their existing accounts in Google, Facebook, Twitter, or Apple to access the 3^rd party website. This is called a 3^rd party sign in. This website is called a 3^rd party since the first two parties are the user and the authentication provider like Google.

The benefit to these websites is that they get to leverage the superior security protocols put in place by the tech giants. Additionally, they avoid the overhead of building any sort of authentication mechanisms themselves on their own websites. 

What is JWT? How Does It Help With Sign in With Apple?

JWT (JSON Web Token) is a mechanism to achieve such 3^rd party sign-ins. Simply put, on a 3^rd party website/mobile app, when a user selects a “Sign in with Apple” option, they are redirected to Apple’s sign-in page. Once the user signs in to Apple (via password, security pattern, security code, fingerprint, or Face ID), Apple issues something called a JWT token to the user. This JWT token is what is allowed access to the 3^rd party app. Sign in with Apple uses this JWT token approach for its 3^rd party sign-ins.

What Was Vulnerable?

A bug bounty hunter identified a flaw in Apple’s 3^rd party sign-in mechanism. The vulnerability was that there was a URL (or a variation of it) exposed by Apple that would return a JWT token based on just an email address and nothing else being mandated. This was not the core URL used for the JWT token generation, but was an orphaned URL. While the core URL performed all the checks, the vulnerable URL did not. So, as long as you have just the email address of the user, you would be able to access the 3^rd party apps using the JWT token. 

This flaw allowed access only to 3^rd party app, but not to any of Apple’s own websites.

How Does Apple Claim That There Was No Misuse?

Thankfully, logging was implemented in the orphaned URL’s flow. This way Apple was able to reconcile if there was any misuse of this security flaw. Gratefully, there was no such misuse.

Lessons Learned

1. Effectively, the issue here was that there was a URL deployed without being tested. This could be either because:       

   1. The URL was not supposed to be deployed at all. It could have been a temporary developer testing URL that was mistakenly deployed. This highlights the need for verifying the list of URLs that would be deployed as well to ensure that nothing untested is deployed.

   2. There was a missing negative test for the actual URL that generates the JWT token. The missing negative scenario here would be requesting the JWT token with just an email address.

2. Despite the flaw, the one aspect that protected the reputation of Apple was proof that there was no misuse of this vulnerability. Hence, the need for appropriate logs for all exposed URLs too.