The resource form parameter on the token request is not validated #30

ClientCredentialsGrant (core/.../oauth/ClientCredentialsGrant.java:84) and TokenExchange (core/.../oauth/TokenExchange.java:66) both add a resource form parameter to the token request. Neither validates it.

This is deliberately not the configured resource identifier: the parameter carries whatever string the caller passes to the grant, and in that position it is the RFC 8707 §2 resource indicator in its primary role — naming the resource a token is being requested for, rather than naming this server.

RFC 8707 §2 still constrains it. It must be an absolute URI and it "MUST NOT include a fragment component", the same requirements now enforced at construction for the identifier this server publishes. A caller passing a fragment-bearing or scheme-relative value today gets whatever the authorization server decides to do with it, which is a worse error than a rejection at the call site naming the requirement.

Scope

Apply the same gates the resource identifier gets, at the two call sites above, before the parameter is added to the form. Reject rather than rewrite.

One thing to decide first: whether rejection is right for a value the SDK forwards rather than owns. The argument for is that an invalid indicator cannot succeed anyway and failing early names the reason. The argument against is that the authorization server is the authority on what it accepts, and an SDK-side gate can refuse something a particular deployment would have honoured. The identifier case had no such tension — that value is published by this server, so this server has to be able to stand behind it.