OpenIdConnect needs additional validation of the response.

[brentschmaltz]

Currently OIDC handler needs to consider the entire message when validating if a message is protocol compliant. Several areas need addressing.

Some are easy: id_token + access_token arrives, the at_hash needs to be evaluated, similar to c_hash. The nonce claim is required in the 'code' and 'token' hybrid flows.

Some are more subtle (from spec):
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.

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.

etc. some we should support, others we may want to leave the validation to the Client since the spec calls out that many times the behavior is Client specific.

At a minimum I suggest:

1. change the API to OpenIdConnectProtocolValidator to take the OpenIdConnectMessage and TBD info.
2. we introduce a delegate, possibly on OIDCPValidator, that can be called for additional validation so that users don't have to derive for custom processing.

[Eilon]

@blowdart by when should we get this done?

[blowdart]

Before the next beta

[Eilon]

@blowdart got it.

@Tratcher putting this on your beta7 plate.

[kevinchalet]

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.

I guess this part depends on AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#53?

The rest sounds like a job for OpenIdConnectProtocolValidator (specially at_hash validation), which is part of Wilson. I'd be curious to know what needs to be added/changed in the OIDC middleware itself.

[Tratcher]

@PinpointTownes's right, almost all of this validation will take place in the identitymodel dependencies. Our OIDC code only needs to be updated if/when there are API changes to pass the needed fields.