magento2: Oauth token request 401 - 'The signature is invalid. Verify and try again.'
Preconditions and environment
On a Magento 2.4.4, I’ve tried connecting a 3rd party service that’s using oauth. It didn’t work, so I’ve tried to check if the endpoint works as expected using Postman. The message ‘The signature is invalid. Verify and try again.’ is haunting on every try.
Steps to reproduce
- Create a new Integration in System -> Integrations.
- Activate it and move to Postman
- In Postman, create a new POST request to /oauth/token/request/ containing the consumer key and secret, access token and token secret in the Authorization section, making sure that
TypeisOAuth 1.0,Add autorization data tois set toRequest HeadersandSignature methodisHMAC-SHA256.
Expected result
According to the documentation , the response should look like
oauth_token=4cqw0r7vo0s5goyyqnjb72sqj3vxwr0h&oauth_token_secret=rig3x3j5a9z5j6d4ubjwyf9f1l21itrr
Actual result
The response is oauth_problem=The+signature+is+invalid.+Verify+and+try+again., with a 401.
Additional information
No response
Release note
No response
Triage and priority
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
About this issue
- Original URL
- State: open
- Created 10 months ago
- Comments: 76 (3 by maintainers)
I don’t understand, how many stores live when this basic functionality is broken?
I also found a related (but not quite same) ticket https://github.com/magento/magento2/issues/37278#issuecomment-1478635403
Thanks for this comment. Though it may not a new issue, badly-formatted URL parameters also cause the server to return this error. For instance, I experienced this due to incorrectly-formatted timestamps in an
ordersquery.It looks like this is being worked on, but having just encountered this issue, the problem appears to lie within the Laminas Oauth library.
Per similar issues on github, if a call to the API is made with data in the URL that contains a slash, it has to be encoded to avoid being interpreted as part of the route. For example a call to the stock API for a SKU “ABC/10” must be encoded to “ABC%2F10”. In turn, when the oauth signature is generated, that part of the URL is encoded and becomes “ABC%252F10”.
When generating the comparative oauth_signature, the Laminas oauth library is normalising the incoming request path back to “ABC/10”. This then unsurprisingly doesn’t result in a matching signature when it’s encoded again to form the oauth sig.
There doesn’t appear to be an option to tell the Laminas library not to do this, so I’m not sure what to suggest as a fix!
https://github.com/laminas/laminas-uri/blob/2.12.x/src/Uri.php#L1310
This didn’t happen prior to 2.4.6 because the Zend Framework signing in use previously doesn’t normalise the URL.
Same issue on 2.4.6-p1
Hi @engcom-Bravo since past week we facing this issue. kindly update on the issue —https://github.com/magento/magento2/issues/38019
Thanks for Advance,.