This is an amazing bug, I am indeed surprised this happened in such a critical protocol. My guess is that nobody must have clearly specified the protocol, and anyone would have been able to catch that in an abstracted english spec.
If this is not the issue, then the implementation might be too complex for people to compare it with the spec (gap between the theory and the practice). I would be extremely interested in a post mortem from Apple.
I have a few follow up questions.
1. seeing how simple the first JWT request is, how can Apple actually authenticate the user at this point?
2. If Apple does not authenticate the user for the first request, how can they check that this bug wasn’t exploited?
3. Anybody can explain what this payload is?
{
"iss": "https://appleid.apple.com",
"aud": "com.XXXX.weblogin",
"exp": 158XXXXXXX,
"iat": 158XXXXXXX,
"sub": "XXXX.XXXXX.XXXX",
"c_hash": "FJXwx9EHQqXXXXXXXX",
"email": "[email protected]", // or "[email protected]"
"email_verified": "true",
"auth_time": 158XXXXXXX,
"nonce_supported": true
}
My guess is that c_hash is the hash of the whole payload and it is kept server side.
If this is not the issue, then the implementation might be too complex for people to compare it with the spec (gap between the theory and the practice). I would be extremely interested in a post mortem from Apple.
I have a few follow up questions.
1. seeing how simple the first JWT request is, how can Apple actually authenticate the user at this point?
2. If Apple does not authenticate the user for the first request, how can they check that this bug wasn’t exploited?
3. Anybody can explain what this payload is?
{ "iss": "https://appleid.apple.com", "aud": "com.XXXX.weblogin", "exp": 158XXXXXXX, "iat": 158XXXXXXX, "sub": "XXXX.XXXXX.XXXX", "c_hash": "FJXwx9EHQqXXXXXXXX", "email": "[email protected]", // or "[email protected]" "email_verified": "true", "auth_time": 158XXXXXXX, "nonce_supported": true }
My guess is that c_hash is the hash of the whole payload and it is kept server side.