3 ms·

What are the security implications of this?

• tusharsoni 7y ago
  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.
  • ec109685 7y ago
    Why would someone be more likely to get a user id compared to your session id?
• pflats 7y ago
  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.
  • ec109685 7y ago
    How does someone eavesdrop on the session?