OIDC client assertion is being rejected incorrectly

[habibrehmansg]

Using CP v2 OIDC results in Incorrect aud in client_assertion claims error when the aud is set correctly to the token endpoint.

The OIDC specs states the aud to be:

A value that identifies the party or parties intended to process
the assertion. The URL of the token endpoint, as defined in
[Section 3.2].

[justin-tay]

Is that what the CorpPass spec says? Does it work in production?

I can't really find the CorpPass spec readily available but the SingPass spec https://stg-id.singpass.gov.sg/docs/authorization/api#_jwt_claims states the aud should match the issuer field

The recipient that the JWT is intended for. This must match the issuer field in the
response of the OpenID discovery endpoint
(https://id.singpass.gov.sg/.well-known/openid-configuration). e.g. https://id.singpass.gov.sg/

The singpass-myinfo-oidc-helper library uses the issuer for the aud claim for the client assertion for CorpPass.

https://github.com/GovTechSG/singpass-myinfo-oidc-helper/blob/319baaacc015809d98a3003c6a4eb457f6530021/src/corppass/corppass-helper-ndi.ts#L120

In general the specs only recommend that the aud is set to the token endpoint but the authorization server is generally free to determine what it should be.

From https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication.

REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Authorization Server as an intended audience.
The Authorization Server MUST verify that it is an intended audience for the token.
The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

Where SHOULD follows RFC2119 definition of

SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

From https://datatracker.ietf.org/doc/html/rfc7523#section-3

The JWT MUST contain an "aud" (audience) claim containing a
value that identifies the authorization server as an intended
audience.  The token endpoint URL of the authorization server
MAY be used as a value for an "aud" element to identify the
authorization server as an intended audience of the JWT.  The
authorization server MUST reject any JWT that does not contain
its own identity as the intended audience.  In the absence of an
application profile specifying otherwise, compliant applications
MUST compare the audience values using the Simple String
Comparison method defined in Section 6.2.1 of RFC 3986.  
As noted in Section 5, the precise strings to be
used as the audience for a given authorization server must be
configured out of band by the authorization server and the
issuer of the JWT.

[habibrehmansg]

Have not gone to production, but it works in staging (https://stg-id.corppass.gov.sg/mga/sps/oauth/oauth20/token).

Unrelated, but this is the default for Nimbus JOSE + JWT SDK for Spring anyway and mockpass broke it, hence my issue.

[cflee]

Corppass Authorization API Reference v1.3 section 5.1.2.1 states that the client assertion JWT claims must have aud as follows:

The recipient that the JWT is intended for. This must match the issuer field in the response of the OpenID discovery endpoint (https://stg-id.corppass.gov.sg/.well-known/openid-configuration). e.g. https://stg-d.corppass.gov.sg

(sic, the later stg-d typo is literally there)

If this is working in Corppass STG, then they either have an implementation issue or a documentation issue.

[habibrehmansg]

The staging also returns data that isn't in the documentation / matched by mockpass such as uuid=UUID and u=String. I guess Ill have to bring all this up with the CP team for clarity.

Actual (redacted) output from CP staging 'sub' response.
's=F..., uuid=..0..b..-...7-..., u=CP200..., c=SG'

Im also assuming that uuid is SP's "u".