Hacker News Reader

Comment by tusharsoni | Hacker News Reader

Developer of a recently launched app with Sign in with Apple here.

I watched the keynote where they launched Sign in with Apple and was honestly surprised at how easy the implementation was. I thought it was a no-brainer to add it to my app. So, I follow their (severely lacking) docs and the keynote and get a solution working. Once the user logs in, their APIs hand you a token that you can then send to the server.

Then, I thought, how do I verify this token on the server? While they do have docs on it [1], they simply omitted it from the keynote to make their example "just work". I would be very surprised if everyone was verifying the token on their servers. Not doing so seems like a loophole for many apps.

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

View on HN

They didn't include more information because they implemented the OpenID Connect specification which is awesome. That means that you can use any OIDC library and it will work for Apple, even verifying the keys. If you want to know more you should read up on OAuth2/OIDC/JWKS.

Apple's public key can be found here.

https://appleid.apple.com/auth/keys

Unless I've missed something, it's worse than that: even if you do verify the token, it only lasts for ten minutes, so you are obligated to tie it to some other form of auth unless you want your users to re-authenticate every ten minutes.

However many developers can correctly follow the meager instructions to validate a token, the number who will properly implement a full auth system is even smaller...

Well, it is called "Sign in with apple", not "Sessions with apple". Keeping sessions in a secure way is on the developer.

What are the security implications of this?

The biggest one is that you're essentially trusting data that the client is providing (Apple gives user id to the client and the client sends it to the server). Unless you can verify the token and exchange it for your own session id, you're opening up your users to be easily impersonated (if they get a hold of the user id).

Other than that, Apple also provides server-side verification for the validity of the token. Without that, the client could send a random string and the server wouldn't know the difference.

Why would someone be more likely to get a user id compared to your session id?

It depends on what the app does and how it does it.

The first step (authenticating) returns a token with your app id, user email address, a unique user id, an expiration time 5m from issuance, and various other info.

Suppose the token is not verified. If the app only uses the email to identify a client, then a malicious/compromised user could pass your app a forged token to access another user's account.

If the app uses email and id, but not the other fields, then a replay attack is possible on a compromised user: the eavesdropper could simply send along an intercepted token to identify as the compromised user. If the timestamp is checked, this gets harder but is still doable.

The other benefit: once you have verified the token, you can also refresh it in the future (1/day max) to silently re-verify the user. If you instead "re-"verify by repeating the initial credential issuance process, the user will be prompted for 2FA verification.

How does someone eavesdrop on the session?

100% agree with this. I had to develop a system to accept Apple tokens and validate them in exchange for our own system's token. When I did this the documentation was sorely lacking (looks the link you posted is fairly recent).

Reply on news.ycombinator.com