ID Token Validation in OIDC flows.

[chamathns]

Description:
In the oidc-sdk, its need to validate the ID Token as per the openid-connect spec [1]. Listing the points below for the ease of reference.

1. If the ID Token is encrypted, decrypt it using the keys and algorithms that the Client specified during Registration that the OP was to use to encrypt the ID Token. If encryption was negotiated with the OP at Registration time and the ID Token is not encrypted, the RP SHOULD reject it.
2. The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim.
3. The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience. The aud (audience) Claim MAY contain an array with more than one element. The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client.
4. If the ID Token contains multiple audiences, the Client SHOULD verify that an azp Claim is present.
5. If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value.
6. If the ID Token is received via direct communication between the Client and the Token Endpoint (which it is in this flow), the TLS server validation MAY be used to validate the issuer in place of checking the token signature. The Client MUST validate the signature of all other ID Tokens according to JWS [JWS] using the algorithm specified in the JWT alg Header Parameter. The Client MUST use the keys provided by the Issuer.
7. The alg value SHOULD be the default of RS256 or the algorithm sent by the Client in the id_token_signed_response_alg parameter during Registration.
8. If the JWT alg Header Parameter uses a MAC based algorithm such as HS256, HS384, or HS512, the octets of the UTF-8 representation of the client_secret corresponding to the client_id contained in the aud (audience) Claim are used as the key to validate the signature. For MAC based algorithms, the behavior is unspecified if the aud is multi-valued or if an azp value is present that is different than the aud value.
9. The current time MUST be before the time represented by the exp Claim.
10. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.
11. If a nonce value was sent in the Authentication Request, a nonce Claim MUST be present and its value checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.
12. If the acr Claim was requested, the Client SHOULD check that the asserted Claim Value is appropriate. The meaning and processing of acr Claim Values is out of scope for this specification.
13. If the auth_time Claim was requested, either through a specific request for this Claim or by using the max_age parameter, the Client SHOULD check the auth_time Claim value and request re-authentication if it determines too much time has elapsed since the last End-User authentication.

Need to test whether each of above points are covered by the SDK flow.

[1] - https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

[darshanasbg]

1. If the ID Token is encrypted, decrypt it using the keys and algorithms that the Client specified during Registration that the OP was to use to encrypt the ID Token. If encryption was negotiated with the OP at Registration time and the ID Token is not encrypted, the RP SHOULD reject it.

Encrypted ID Tokens are not supporting ATM. Hence this point is NA as of now. Adding the support of encrypted ID Tokens are tracked with #3.

[darshanasbg]

2. The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim.

Verification is in place at https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/src/354fd08849407cb5b1fe26026c01bba3e647c096/src/main/java/com/nimbusds/openid/connect/sdk/validators/IDTokenClaimsVerifier.java#lines-172. Tested manually and confirmed.

[chamathns]

3. The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience. The aud (audience) Claim MAY contain an array with more than one element. The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client.

Verification for, "The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience." , is in place at https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/src/354fd08849407cb5b1fe26026c01bba3e647c096/src/main/java/com/nimbusds/openid/connect/sdk/validators/IDTokenClaimsVerifier.java#lines-186. Tested manually and confirmed.
Multiple audience validation is not supported at the moment and it is tracked with #6.

[chamathns]

4. If the ID Token contains multiple audiences, the Client SHOULD verify that an azp Claim is present.

Verification is in place at https://github.com/ChamathNS/asgardio-java-oidc-sdk/blob/324e1c62bff52958b611527674cda6746fe531c2/io.asgardio.java.oidc.sdk/src/main/java/io/asgardio/java/oidc/sdk/OIDCManagerImpl.java#L249. Tested manually and confirmed. (Update link once merged.)

[chamathns]

5. If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value.

Verification is in place at https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/src/368d830e49f0f0a30cee7ae80c6bedcdb8ebfa49/src/main/java/com/nimbusds/openid/connect/sdk/validators/IDTokenClaimsVerifier.java#lines-202. Tested manually and confirmed.

[chamathns]

6. If the ID Token is received via direct communication between the Client and the Token Endpoint (which it is in this flow), the TLS server validation MAY be used to validate the issuer in place of checking the token signature. The Client MUST validate the signature of all other ID Tokens according to JWS [JWS] using the algorithm specified in the JWT alg Header Parameter. The Client MUST use the keys provided by the Issuer.

Verification is in place at https://bitbucket.org/connect2id/nimbus-jose-jwt/src/f35500971243460a1e044357f04202e626c4825a/src/main/java/com/nimbusds/jwt/proc/DefaultJWTProcessor.java#lines-383. Tested manually and confirmed.

[chamathns]

7. The alg value SHOULD be the default of RS256 or the algorithm sent by the Client in the id_token_signed_response_alg parameter during Registration.

Verification is at https://github.com/ChamathNS/asgardio-java-oidc-sdk/blob/c91a7e9ff68919b24382d0ec78164209c6f35053/io.asgardio.java.oidc.sdk/src/main/java/io/asgardio/java/oidc/sdk/OIDCManagerImpl.java#L282-L292. Tested manually and confirmed. (Update link once merged.)

[chamathns]

8. If the JWT alg Header Parameter uses a MAC based algorithm such as HS256, HS384, or HS512, the octets of the UTF-8 representation of the client_secret corresponding to the client_id contained in the aud (audience) Claim are used as the key to validate the signature. For MAC based algorithms, the behavior is unspecified if the aud is multi-valued or if an azp value is present that is different than the aud value.

Verification is at https://bitbucket.org/connect2id/nimbus-jose-jwt/src/master/src/main/java/com/nimbusds/jose/jwk/source/ImmutableSecret.java#lines-47 and https://bitbucket.org/connect2id/nimbus-jose-jwt/src/d65f9ffd13616ee1f9f1a4672d0e84dd7e7a7669/src/main/java/com/nimbusds/jwt/proc/DefaultJWTProcessor.java#lines-384. Tested manually and confirmed.

[chamathns]

9. The current time MUST be before the time represented by the exp Claim.

Verification is in place at https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/src/368d830e49f0f0a30cee7ae80c6bedcdb8ebfa49/src/main/java/com/nimbusds/openid/connect/sdk/validators/IDTokenClaimsVerifier.java#lines-224. Tested manually and confirmed.

[chamathns]

10. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.

This behavior is not currently supported. Adding support for iat claim based validation is tracked at #7.

[chamathns]

11. If a nonce value was sent in the Authentication Request, a nonce Claim MUST be present and its value checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.

Validation is in place at https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/src/368d830e49f0f0a30cee7ae80c6bedcdb8ebfa49/src/main/java/com/nimbusds/openid/connect/sdk/validators/IDTokenClaimsVerifier.java#lines-248. Tested manually and confirmed.

[chamathns]

12. If the acr Claim was requested, the Client SHOULD check that the asserted Claim Value is appropriate. The meaning and processing of acr Claim Values is out of scope for this specification.

There is no support for acr_values or acr claim in the SDK at the moment. Since this is optional, it is considered to be an improvement and it is tracked by #8.

[chamathns]

13. If the auth_time Claim was requested, either through a specific request for this Claim or by using the max_age parameter, the Client SHOULD check the auth_time Claim value and request re-authentication if it determines too much time has elapsed since the last End-User authentication.

This improvement is tracked by #9.