Incorrect Parameter-Encoding in Authorization-String about oauth1-signer-java HOT 4 CLOSED

Hi,
you are right. I personally do not depend on a fix to this issue. We just implemented the OAuth standard to get authorized at MDES. This is done independently of your demo implementation and based on the original OAuth1.0a + the documented Extensions. However it seems that your server-side both accepts correctly generated data according to OAuth1.0a+Extensions and also according to your individual adaption of the standard. It would have been a problem if the servers were to reject our requests. But thats not the case. They seem to rely on a different implementation logic.

So, I wouldn't mind if you prefer to reject this issue.
I only wanted to give a hint that this implementation is not base on OAuth1.0a+Extensions although it should be the case according to your documentation. See your own reference to https://tools.ietf.org/html/rfc5849 in your JavaDoc. Even the Mastercard Developers documentation on the website you provided states that the protocol is indeed OAuth1.0a extended by an alternative signature scheme and the Google Body Hash Extension. There is no hint for further extensions or modifications. Thats why I do not fully agree with your reasoning that the alternative parameter encoding is comparable to the usage of the Google Body Hash extension. Its a documented extension which has been proposed to the IETF. On the other hand the alternative parameter encoding is a undocumented modification without any further reasoning.

I think it would be helpful to other Mastercard customers if it would explicitly be stated that the protocol relies on a standard which looks almost like OAuth1.0a+Extensions, but is indeed a proprietary standard or otherwise this issue is considered a problem with the implementation.

Thank you!

from oauth1-signer-java.

Hi @moritz1895,

A different encoding and the usage of extensions aren't at the same level. I simply wanted to highlight there are differences, and this is something we are aware of.

What is important for us is client applications can consume Mastercard APIs regardless of if they use this lib or their own implementation.

There is no reason for us to reject this issue you opened as we have it in our backlog already. It was simply assigned a lower priority since it's not a blocker and can be fixed transparently by publishing a new version of this library (and of course because it doesn't introduce vulnerabilities).

By the way, this is an open source project. Since you coded your own OAuth stuff, any contribution is welcome :)

Best regards,

from oauth1-signer-java.

Hi @moritz1895,

Thanks for having opened this issue!

This library was designed to be used with Mastercard APIs available in the Mastercard Developer Portal (see also: Using OAuth 1.0a to Access Mastercard APIs).

If you experience any issue in this context, please provide some more details so that we can reproduce and fix the problem (like the API name and the endpoint/request).

To answer your question, yes, there are a few differences between this implementation and the specification, for instance the usage of RSA-SHA256 or of a body hash.

from oauth1-signer-java.

Won't fix for now since the lib is working with Mastercard APIs.

from oauth1-signer-java.