imn2
This is very helpful. Thanks so much!
I believe there may be some confusion in here. The “state” field is used for transmitting key/value, boolean, etc. info to Apple, which will come back to your server when Apple calls your server back. A classical example of useful state to send and then later receive back would be the “stay logged in” boolean state. This state is related to the attempt to authenticate itself, and makes most sense to be able to recover this state as the authentication process moves forward, without need to persist state in a DB on the server.
I think you may be talking about the “nonce” field, which is used for preventing replay attacks, not CSRF. This field should be set to some random value, and that random value should be checked against the nonce field in the auth response.
All this said, I have not used Apple Sign In yet. But from having done OAuth in Google-land and used state fields to transmit such state as “stay logged in”, and having used nonces in cryptography, I think your writeup might be improvable.
Further, I am not totally certain why Apple needs this nonce. This may be because Apple does not assume that auth travels only over TLS/SSL. Apple’s response is always over TLS/SSL, but I don’t see the requirement that the server itself initiates auth over TLS/SSL. That may be why the nonce is necessary, to ensure that multiple auth initiations from the same user do not generate the same locally encrypted string. That would be vulnerable to attack. I would think that if you are actually initiating auth over TLS/SSL, then creating and/or checking the nonce is unnecessary… but I don’t know Apple’s implementation details on this, so be careful 