search

amzn / selling-partner-api-models

This repository contains OpenAPI models for developers to use when developing software to call Selling Partner APIs.
Apache License 2.0
580 stars 730 forks source link

[BUG] Oauth Documentation does not cover renewals #2950

Closed kpconnell closed 1 year ago

kpconnell commented 2 years ago

Describe the bug Credential / authorization renewal flow is not documented.

URL of the content on GitHub https://developer-docs.amazon.com/sp-api/docs/authorizing-selling-partner-api-applications

Description of what the documentation currently says It does not say anything

Description of what the documentation should say It should detail how the developer/application Oauth urls are called by seller central, and in particular, what to expect for state and how to determine (since state is transient) which seller seller central is redirecting from.

Landsailor commented 2 years ago

It should be documented, but it's no big deal.

Renewals are handled exactly like a brand new authorization following the Amazon SCPN authorization workflow

The call initiated by Step 2 when the Seller clicks the "authorize" button contains _selling_partnerid, so you use that as your key.

Here's a screenshot from our first client to renew after we migrated:

SP-API Renewal Screenshot
moltar commented 2 years ago

Is there any notification to the user? Any system notification? Can this information be obtained from the API? How do I know who needs a renewal?

kpconnell commented 2 years ago

Uhh. you've linked back the same documentation that is identified in the BUG as having a BUG and it is not that simple.

It should be documented, but it's no big deal.

Renewals are handled exactly like a brand new authorization following the Amazon SCPN authorization workflow

The call initiated by Step 2 when the Seller clicks the "authorize" button contains _selling_partnerid, so you use that as your key.

Here's a screenshot from our first client to renew after we migrated: SP-API Renewal Screenshot

kpconnell commented 2 years ago

I cannot for the life of me figure out how this renew process is intended to be secure....

Landsailor commented 2 years ago

Refresh_tokens are good for one year (which make sense since a Seller has to renew every year).

Just like in MWS, there's no automated notification (that I've seen, anyway) that a refresh token is about to expire, so just create _refresh_tokenexpiration in your system and set a timestamp that is 358 days from the date it is created so you have about a week's notice.

Send out an email or call them to remind them. I think Amazon may send them notices, too.

Another indicator of an expired MWS Token/SP Refresh Token is the errors in your logs that usually correspond with a string of angry emails wondering why you're not downloading orders. :)

Landsailor commented 2 years ago

It literally is exactly the same as an initial authorization. Zero difference to your server. You do everything exactly the same. The only difference for the client is the text in the button, as shown.

  • How does selling partner authenticate the redirect (can't just use seller id, shouldn't be using stale state)

It won't. Amazon sends a fresh _amazonstate, every request.

  • What is the flow after SC redirects client back to you? Do you send back a fresh state and should expect new tokens coming back?

The state your system returns is supposed to be short lived, as well. If you're persisting the state for some reason, then fix that.

I cannot for the life of me figure out how this renew process is intended to be secure....

It's exactly as secure as the first authorization.

  1. The seller logs into their Amazon account.
  2. Seller clicks button.
  3. Seller authorizes Amazon to send data to you.
  4. Seller logs into your system.
  5. Both servers check the states sent back and forth to see if anyone is up to any shenanigans. Data is exchanged.
  6. New tokens are created.
  7. Profit!

If you're skipping any of the steps, you're increasing your vulnerabilities to bad actors.

Yes, the docs need to say "Renewals are handled exactly as initial authorizations", but if your server is designed according to Amazon's specs, you won't notice whether it's a renewal, a new registration, or a new renewal after someone accidentally clicked the wrong button and deleted the old one.

moltar commented 2 years ago

It literally is exactly the same

It literally cannot be.

Because:

kpconnell commented 2 years ago

It won't. Amazon sends a fresh _amazonstate, every request.

So, no, not exactly like the initial flow - initial flow is you authenticate user on your side, you send the user to amazon with your state, and Amazon also sends back user with YOUR state along with theirs. This state is vitally important for validating seller central is trying to move forward with the same. The renewal flow, in order to actually be secure, (and at the same time be annoying to the user), you would have to take a renewal redirect and start the entire process over - which would work, but it is not the same flow. You absolutely should not "continue" the flow of a renewal given the first redirect. You have no information telling you it came from seller central!

kpconnell commented 2 years ago

It literally is exactly the same

It literally cannot be.

Because:

  • Which redirect URL will they use? You can have more than one. It is specified during OAuth redirect.
  • How can they supply the state query param, which is generated by us during the redirect

Bingo

Landsailor commented 2 years ago

It literally is exactly the same

It literally cannot be.

Because:

  • Which redirect URL will they use? You can have more than one. It is specified during OAuth redirect.

You chose to use the Website Authorization Workflow . It's the easier way to do it, for sure. I didn't want to hobble my users by not supporting the Amazon SCPN authorization workflow. Plus it can also generate new clients from finding you in the app listings.

The docs clearly state that the first OAuth redirect is the default, but you can choose to return any that are listed.

moltar commented 2 years ago

Right, but default != "exactly the same as original auth URL"

What if we have different URLs for different purposes?

Think Seller Central vs Vendor Central.

We can't have two defaults.

Landsailor commented 2 years ago

It literally is exactly the same

It literally cannot be. Because:

  • Which redirect URL will they use? You can have more than one. It is specified during OAuth redirect.
  • How can they supply the state query param, which is generated by us during the redirect

Bingo

Never heard of the Amazon SCPN authorization workflow, huh?

Sure, only supporting website authorization is the easy way because you save a whole step, but I didn't want to have to explain to my clients why I chose to make their lives more difficult by not supporting the button that Amazon provides.

It's really bad optics to have a button linked to your company that literally does nothing.

You made your point, though. Your "bug" languished with no responses for over two freakin' weeks. I shared knowledge that you didn't have and obviously should not have wasted my time.

You're welcome for the education.

Landsailor commented 2 years ago

Right, but default != "exactly the same as original auth URL"

What if we have different URLs for different purposes?

Think Seller Central vs Vendor Central.

We can't have two defaults.

You could always evaluate the client's data on your end and perform a redirect. I don't know your system nor how it's set up.

If an Amazon Seller clicks the "Renew" button, as illustrated in the screenshot, then it absolutely, positively is exactly the same process as the first auth method listed in the SP-API docs.

For website auth workflows, based on my testing before our app was published, it just generates a new refresh token every time. I assume it would also update the Seller's expiration date, too, but I haven't run that same test now that we're in production

Personally, I did not want to have to explain to clients why they couldn't just use the handy, dandy button provided by Amazon and have a button that doesn't work on Amazon's site. It's bad form to have to remind people "Oh, don't click that button. Login to our website first."

You do you, though.

kpconnell commented 2 years ago

you are missing the point about security and I don't think you understand several use cases. authing a user from a redirect containing a seller id is a patently bad idea. that should 100% result in you kicking them to auth on your side and start the flow over.

On Thu, Aug 11, 2022, 12:10 PM Landsailor @.***> wrote:

Right, but default != "exactly the same as original auth URL"

What if we have different URLs for different purposes?

Think Seller Central vs Vendor Central.

We can't have two defaults.

You could always evaluate the client's data on your end and perform a redirect. I don't know your system nor how it's set up.

If an Amazon Seller clicks the "Renew" button, as illustrated in the screenshot, then it absolutely, positively is exactly the same process as the first auth method listed in the SP-API docs.

For website auth workflows, based on my testing before our app was published, it just generates a new refresh token every time. I assume it would also update the Seller's expiration date, too, but I haven't run that same test now that we're in production

Personally, I did not want to have to explain to clients why they couldn't just use the handy, dandy button provided by Amazon and have a button that doesn't work on Amazon's site. It's bad form to have to remind people "Oh, don't click that button. Login to our website first."

You do you, though.

— Reply to this email directly, view it on GitHub https://github.com/amzn/selling-partner-api-models/issues/2950, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIHBZSPU276PYK3IXBZMDDVYRAIFANCNFSM54OU7GOQ . You are receiving this because you authored the thread.Message ID: @.***>

Landsailor commented 2 years ago

If that's what you're choosing to do, then I agree. That's a bad idea.

If you can point me to the place where Amazon instructs you to authenticate a user based solely on the Seller ID, then please do so.

On my screen, it clearly states "The selling partner signs into your website. If the selling partner does not yet have an account, they complete your registration process.", but I don't know what documentation you're viewing.

github-actions[bot] commented 1 year ago

This is a very old issue that is probably not getting as much attention as it deserves. We encourage you to check if this is still an issue after the latest release and if you find that this is still a problem, please feel free to open a new issue and make a reference to this one.

github-actions[bot] commented 1 year ago

closed for inactivity