Magento 2 - OAuth Problem = Consumer Key Has Expired

[itsabe]

Preconditions

1. Magento Version 2.4
2. Set up and activated API Integration with full access

Steps to reproduce

1. Create integrations
2. Make POST call to /oauth/token/request

Expected result

1. Get request token

Actual result

1. oauth_problem=Consumer+key+has+expired

I tried it with two different integrations, both are activated, and both return the same response of "consumer key has expired"

[phpandrew]

Seems this issue is present in 2.4 as well.

You are likely generating the key/secret and using that to try and authorize.

The flow of Magento is different from other marketplaces.

Under the store admin > System > Integrations > Add New Authorization You need to setup the identify and callback URLs to get the consumer key/secret. Callback URl will be called first, authorize the user on your platform, store the posted credentials (key, secret, verifier, and store url.) you get from this and return HTTP 200 success.

The identify URI will be called next, use the credentials you captured to send a request to store_url.com/oauth/token/request and in the same script, get your second access token and secret by posting to store_url.com/oauth/token/access

Hope this helps. Let me know if you want me to provide PHP example code.

[ringwood-dsg]

Seems this issue is present in 2.4 as well.

You are likely generating the key/secret and using that to try and authorize.

The flow of Magento is different from other marketplaces.

Under the store admin > System > Integrations > Add New Authorization You need to setup the identify and callback URLs to get the consumer key/secret. Callback URl will be called first, authorize the user on your platform, store the posted credentials (key, secret, verifier, and store url.) you get from this and return HTTP 200 success.

The identify URI will be called next, use the credentials you captured to send a request to store_url.com/oauth/token/request and in the same script, get your second access token and secret by posting to store_url.com/oauth/token/access

Hope this helps. Let me know if you want me to provide PHP example code.

Thank you for clearing this up for me. I find your explanation regarding the sequence of events a lot helpful than the official manual, to be quite honest. We're integrating our .NET application with Magento, but what I am unsure of is the parameters being passed to the Callback URL? I see the manual references it like this:

• store_base_url
• oauth_verifier
• oauth_consumer_key
• oauth_consumer_secret

Am I correct in saying that when our callback URL is being called, that the parameters will be named exactly as they are referenced above?

[phpandrew]

Seems this issue is present in 2.4 as well.

You are likely generating the key/secret and using that to try and authorize. The flow of Magento is different from other marketplaces. Under the store admin > System > Integrations > Add New Authorization You need to setup the identify and callback URLs to get the consumer key/secret. Callback URl will be called first, authorize the user on your platform, store the posted credentials (key, secret, verifier, and store url.) you get from this and return HTTP 200 success. The identify URI will be called next, use the credentials you captured to send a request to store_url.com/oauth/token/request and in the same script, get your second access token and secret by posting to store_url.com/oauth/token/access Hope this helps. Let me know if you want me to provide PHP example code.

Thank you for clearing this up for me. I find your explanation regarding the sequence of events a lot helpful than the official manual, to be quite honest. We're integrating our .NET application with Magento, but what I am unsure of is the parameters being passed to the Callback URL? I see the manual references it like this:

• store_base_url
• oauth_verifier
• oauth_consumer_key
• oauth_consumer_secret

Am I correct in saying that when our callback URL is being called, that the parameters will be named exactly as they are referenced above?

Yes, those variables will be posted exactly as that to the callback link. No data is posted to the indentify URL, that you will need to pull the session data / from the DB and POST that back to the magento store to the oauth/token/request, then make another POST request to the oauth/token/access url

[ringwood-dsg]

Seems this issue is present in 2.4 as well.

You are likely generating the key/secret and using that to try and authorize. The flow of Magento is different from other marketplaces. Under the store admin > System > Integrations > Add New Authorization You need to setup the identify and callback URLs to get the consumer key/secret. Callback URl will be called first, authorize the user on your platform, store the posted credentials (key, secret, verifier, and store url.) you get from this and return HTTP 200 success. The identify URI will be called next, use the credentials you captured to send a request to store_url.com/oauth/token/request and in the same script, get your second access token and secret by posting to store_url.com/oauth/token/access Hope this helps. Let me know if you want me to provide PHP example code.

Thank you for clearing this up for me. I find your explanation regarding the sequence of events a lot helpful than the official manual, to be quite honest. We're integrating our .NET application with Magento, but what I am unsure of is the parameters being passed to the Callback URL? I see the manual references it like this:

• store_base_url
• oauth_verifier
• oauth_consumer_key
• oauth_consumer_secret

Am I correct in saying that when our callback URL is being called, that the parameters will be named exactly as they are referenced above?

Yes, those variables will be posted exactly as that to the callback link. No data is posted to the indentify URL, that you will need to pull the session data / from the DB and POST that back to the magento store to the oauth/token/request, then make another POST request to the oauth/token/access url

Thank you so much for taking the time to assist me here. I'll continue on from here and get our integration completed using your instructions. You are definitely the Magento King and my hero!

[lbajsarowicz]

I'm encountering the issues described in this Bug Report, but problem seems to be a little bit more complex:

When I'm calling simple endpoints, everything works more-less correct:

However, the same keys used to fetch the Invoices ends up with "The signature is invalid"

But it works completely fine if you don't use SearchCriteria:

Looks like there's some mess around calculating request signature 👎🏻

The issue appears when the URL is urlencoded:

[DEHAINI]

secret

can u please gie me a clear example? i have the same issue and i can not resolve it

[shenoyaditya11]

I found the source of my issue. Upon creating the integration and activating it, I get a consumer key, consumer secret, access token, and access token secret. So, technically, I can just skip the "Get Access Token" step of the authentication. I was able to successfully make API calls with the provided access token.

If I created the integration with an Identity link URL, then the access token and access token secret is not supplied. And when I made a request to /oauth/token/request, I got the access token and secret as a response.

If this was the intended process, then my apologies for misinterpreting the documentation.

I tried creating Integration with the Identity link, it still creates access token and token secret on activation. and before activation if I try to hit /oauth/token/request, it throws Consumer+key+expired, how to fix this issue, please help.

[jakwinkler]

Look at my comment here: https://github.com/magento/magento2/issues/13961#issuecomment-625284593

[jmwill86]

It's been almost 6 years since this was created, it's been marked as closed even though the issue was never actually resolved. The lack of care Magento have for their codebase is second to none.

I'd normally be happy to try and help fix things like this, but if you can't be bothered after 6 years, why should I.