#396 - Set the id token if it is returned via the refreshToken endpoint

[c0ntax]

If the id token is present when refreshing, capture it

[ricklambrechts]

Do we need to validate the id_token?

OpenID-Connect-PHP/src/OpenIDConnectClient.php

Lines 341 to 353 in 5d69bcf

	$claims = $this->decodeJWT($id_token, 1);
	// Verify the signature
	$this->verifySignatures($id_token);
	// Save the id token
	$this->idToken = $id_token;
	// Save the access token
	$this->accessToken = $token_json->access_token;
	// If this is a valid claim
	if ($this->verifyJWTClaims($claims, $token_json->access_token)) {

[c0ntax]

@ricklambrechts technically, yes. There are a load of rules in the spec:

If an ID Token is returned as a result of a token refresh request, the following requirements apply:

• its iss Claim Value MUST be the same as in the ID Token issued when the original authentication occurred,
• its sub Claim Value MUST be the same as in the ID Token issued when the original authentication occurred,
• its iat Claim MUST represent the time that the new ID Token is issued,
• its aud Claim Value MUST be the same as in the ID Token issued when the original authentication occurred,
• if the ID Token contains an auth_time Claim, its value MUST represent the time of the original authentication - not the time that the new ID token is issued,
• its azp Claim Value MUST be the same as in the ID Token issued when the original authentication occurred; if no azp Claim was present in the original ID Token, one MUST NOT be present in the new ID Token, and
  otherwise, the same rules apply as apply when issuing an ID Token at the time of the original authentication.

But I err'd on the side of the same amount of validation that's going on for the accessToken as part of the refreshToken grant (which is 'does it exist? Yes. Therefore it is valid') ;-)

I'd suggest creating another ticket for token validation as part of the refresh mechanism and tackle the problem incrementally

[timoschinkel]

I agree with both; typically the id token is not stored, so there might not be access to the previous id token. By if the user has it available, then verifying it makes sense. Maybe at the very least the JWT signature can be verified. The access token can be any string according to the spec, but the id token should be a JWT by specification.