[BUG] Token endpoint does not enforce mandated DPoP; fetchUserinfo fails later with incorrect "session expired" message when RP only implements PAR (client mandates FAPI: PAR + DPoP + PKCE)

[prathmeshj12]

Description

When a client is registered with full FAPI mandate — require_pushed_authorization_requests (PAR), dpop_bound_access_tokens (DPoP), and PKCE all required — but the RP only implements/enables PAR (not DPoP), the request should already fail at the /oauth2/token step: since DPoP is mandated for this client, token issuance without a DPoP proof should be rejected there. Instead, the token endpoint incorrectly succeeds and issues an access token despite no DPoP proof being sent. The failure only surfaces later, at fetchUserinfo, and even then the RP portal displays a misleading "session expired" message instead of a descriptive error pointing to the real cause (missing DPoP proof).

Steps to Reproduce

Preconditions

1. A client is registered with full FAPI mandate: PAR + DPoP + PKCE all required.
2. The RP application/portal used for testing implements PAR correctly but does not implement DPoP (does not attach a DPoP proof at token exchange and/or userinfo).

Rancher property:
            - name: PAR_CALLBACK_NAME
              value: get_requestUri
            - name: PAR_CALLBACK_TIMEOUT
              value: '5000'
            - name: DPOP_CALLBACK_NAME
              value: get_dpop_jkt1
            - name: CODE_CHALLENGE
              value: get_code_challenge

### Steps:

1. Launch the https://healthservices-go.esqa.mosip.net/
2. Click on sign in with eSignet.
3. Perform the L2 flow
4. Observed the issue in fetchuserinfo and RP portal.

### Actual Result:
/token incorrectly succeeds and issues an access token even though DPoP is mandated for the client and no DPoP proof was sent. The request only fails later, at fetchUserinfo, and the RP portal displays "session expired" — a message that has nothing to do with the actual cause (a missing mandated DPoP proof, which should have been caught at token issuance).

Expected Behavior

Since DPoP is mandated for this client, /token endpoint should reject the request outright when no DPoP proof is present — e.g. with invalid_dpop_proof or an equivalently specific error (per RFC 9449) and a descriptive error_description such as "DPoP proof is required for this client" — rather than issuing an access token.

Attachment / Evidence / Docs / Screenshots

Screen.Recording.2026-09-11.at.8.42.41.AM.mov

Root Cause

No response

Additional Context

No response