Bug found: HS512 is used to sign OIDC JWT access token if OidcRegisteredService.idTokenSigningAlg is set

[leeyc0]

I am testing OIDC with ES256 to sign JWT. But I found that if I configured OidcRegisteredService.idTokenSigningAlg to use ES256, the access token is signed with HS512 using cas.authn.oauth.accessToken.crypto.signing.key instead. (The ID token is signed with ES256 as expected.) This causes access key introspection to fail.

If I removed OidcRegisteredService.idTokenSigningAlg, access token is signed with RS512 and ID token is signed with RS256. In this case access key introspection works as intended.

I am not sure how to fix this bug, so I am posting here for suggestion.

[leeyc0]

I think I found the bug. core/cas-server-core-util-api/src/main/java/org/apereo/cas/util/cipher/AbstractCipherExecutor.java and core/cas-server-core-util-api/src/main/java/org/apereo/cas/util/EncodingUtils.java simply do not support elliptic curve. What a shame...

leeyc0於 2020年5月1日星期五 UTC+8下午6時15分27秒寫道：

[leeyc0]

I have fixed AbstractCipherExecutor and EncodingUtils to support ECDSA. But now I am facing another problem.

Oauth2 access token is generated twice, first in OAuth20JwtAccessTokenEncoder and the second OidcIdTokenGeneratorService, and the second output is used to calculate at_hash in OIDC id_token
OidcIdTokenGeneratorService. Now the problem is for ECDSA, a noune is required to generates a signature. Therefore, even for identical input,
signature output is difference every time.

Therefore, to support ECDSA, the access token in OidcIdTokenGeneratorService must NOT be re-generated, but rather taken from the output of OAuth20JwtAccessTokenEncoder, otherwise at_hash would be broken. I really need help now, since the code flow seems do not support such operation.