[REQ] Split OAuth.java internals to not depend on Java PrivateKey interface (or by default software keys)

[martinpaljak]

Is your feature request related to a problem? Please describe.

Would love to sign requests with a hardware key while not using JCA keys. That is, I'd like to get access to the DTBS or hash of it separately from the all-in-one "sign and get header value" operation. It seems (see #18 (comment)) that providing access to exactly this kind of serialization is exactly why this library exists.

Describe the solution you'd like

Split OAuth.java to a) generate the "data to be signed" and/or hash of it b) provide a way to provide the signature value (binary) for generating the string representations and attaching to a request. (c) don't generate the nonce internally or provide a way to provide this nonce from caller, or from a specific random source, and keep it as byte[] internally)

Alternatively, a small functional "signature provider" (or maybe Function if 1.8 could be targeted, which I see is not the case from comments and code specifically existing for 1.6) interface might make sense, that would be less "demanding" than implementing JCA PrivateKey mockups for API based signing.

While the code is generously MIT and I just copied the OAuth java (also Util.java due to the "I don't want to research if the .replace() calls in URLEncodign are needed or not) it would be nice if the library could be re-used (developers like the interceptors and signers for various client libs) yet support non-JCA approaches to hardware based signing.

[NehaSony]

Hi @martinpaljak
Thanks for the request.
The purpose of this library is for generating a Mastercard API compliant OAuth signature. This makes our use-case specific to signing using a client RSA private key and, in our case, it is RSA-SHA256. Hence we do not support hardware keys to sign the request.

[martinpaljak]

Nothing about RSA private keys or RSA-SHA256 contradicts the use of hardware keys. The issue at hand here is the internal implementation of the minilibrary, that could easily be more flexible without sacrificing current use, so that it could be included as a dependency, rather than a copy-paste source.