Context
#4179 added server-side scope policy enforcement (profile-only / passthrough / dynamic) to the S2S vp_token flow in handleS2SAccessTokenRequest. The OpenID4VP / authorization-code flow takes a separate path to createAccessToken that does not invoke grantedScopesForPolicy — so scope policy is currently not enforced for that flow.
Problem
In auth/api/iam/openid4vp.go the auth-code handler uses oauthSession.Scope (the raw requested scope) and passes it directly to createAccessToken. This means:
- profile-only: extra scopes are NOT rejected
- dynamic: the AuthZen PDP is NOT called; extra scopes pass through without evaluation
- passthrough: works by accident (raw scope is forwarded)
A client going through the auth-code flow can request arbitrary extra scopes and receive them in the issued access token — bypassing the policy that's enforced on the S2S path.
Expected behaviour
Same as the S2S flow:
- Look up the credential profile via
FindCredentialProfile
- Reject profile-only + extras
- Call the AuthZen PDP for dynamic
- Issue token with only granted scopes
Related
Context
#4179 added server-side scope policy enforcement (profile-only / passthrough / dynamic) to the S2S
vp_tokenflow inhandleS2SAccessTokenRequest. The OpenID4VP / authorization-code flow takes a separate path tocreateAccessTokenthat does not invokegrantedScopesForPolicy— so scope policy is currently not enforced for that flow.Problem
In
auth/api/iam/openid4vp.gothe auth-code handler usesoauthSession.Scope(the raw requested scope) and passes it directly tocreateAccessToken. This means:A client going through the auth-code flow can request arbitrary extra scopes and receive them in the issued access token — bypassing the policy that's enforced on the S2S path.
Expected behaviour
Same as the S2S flow:
FindCredentialProfileRelated