Authenticate using STS vs user permission

[p-prins]

I tested two authentication strategies to make calls to the sandbox:

1. Using STS (as documented)
2. Using a user permission

In the second approach give the user permission to use the documented policy, i.e.:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "execute-api:Invoke",
            "Resource": "arn:aws:execute-api:*:*:*"
        }
    ]
}

The second approach has the obvious benefit that it does not require the use of STS.

What are the consequences of using the second approach in production? If there aren't any consequences, why is this not the documented (default) approach?

[charliecode]

Hello @p-prins! I haven't followed the second approach all the way through, so I can't speak to that. What I can say, coming from working with the previous MWS API for the past 3 years, is that security must definitely have been at the top of the list when Amazon decided to create the new SP-API. Over the years we've seen Amazon take the security of sellers data more and more serious. With the new SP-API one of the things that really stands out is how much more secure it is than MWS. And I would imagine that's one of the reasons you're seeing the first approach encouraged. By default those credentials are only good for 1 hour. You can even dial that down to 15min if you'd like, which would honestly be even more secure and better in production. More security is a very good thing, especially when you're in charge of sellers data.

[ericblade]

... here I am noting that the documentation goes through configuring it for using it with STS, but the documentation on actually making calls does not mention STS at all, so there's a disconnect there, which is currently preventing a lot of us from getting in, it would seem.

Clearly, adding STS adds another layer of API calls that need to be performed, but it's not clear if that's necessary or even what was intended. I'm not super familiar with STS -- I haven't used AWS services in a couple of years, it's expanded quite a bit since last I was poking around in there -- but I do question if there's any point to adding another layer of tokens necessary.

Please correct me if I'm wrong, but it seems that if you follow the documentation for "how to configure your IAM user" here in the sp-api, the process for making a service call seems to be:

1) get sp_oauth_token from server using LWA secret key and access key 2) exchange sp_oauth_token for an access_token/refresh_token combination, using the IAM user secret key and access key 3) use that access_token to call STS AssumeRole() on your Role's ARN, which returns a secret access key, an access key id, and a session token 4) use the secret access key, access key id, and session token from step 3 and the access token returned from step 2 to make sp-api calls 5) when the access_token received in step 2 expires, exchange the refresh_token from step 2 for another access_token, repeat step 3 6) ???

whereas the documentation currently seems to indicate step 1 and 2 is correct, then you just use the access_token in step 2 to access the service, until it expires, then exchange the refresh_token from step 2, and you're good.

am I wrong on any of this?

[p-prins]

@charliecode, I agree this API is more secure 🙌. Regarding this specific issue, I don't think that STS adds security. In fact, one could argue that using STS decreases security as it offers another attack surface. Now I don't think this has any practical implications, because, if used correctly, AWS' services are highly secure.

@ericblade, that's looks familiar. If you're going the STS route, don't forget to sign the request using the STS token. This comment might help you: https://github.com/amzn/selling-partner-api-models/issues/690.

@seanevan could you, or someone else working at Amazon, give a formal reply on this issue?

[ericblade]

@p-prins ok, i've updated my step 4 there, based on the code example you linked. it feels excessive -- if you're starting from the beginning, to get to actually making a call, you need: oauth token, lwa secret key, lwa access key, iam user secret key, iam user access key, role arn, role secret access key, role access key id, session token, oauth access token, and oauth refresh token (for later regeneration of several of those variables). the static information is the lwa secret, lwa access, iam user secret, iam user access, and role arn .. and the rest are derived from those and the oauth key.

am i correct now?

[p-prins]

From the top of my head, I think you're correct. We'll have to await Amazon's response to this issue to determine whether the "user permission" approach is also OK.

[ramieblatt]

I tested two authentication strategies to make calls to the sandbox:

1. Using STS (as documented)
2. Using a user permission

In the second approach give the user permission to use the documented policy, i.e.:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "execute-api:Invoke",
            "Resource": "arn:aws:execute-api:*:*:*"
        }
    ]
}

The second approach has the obvious benefit that it does not require the use of STS.

What are the consequences of using the second approach in production? If there aren't any consequences, why is this not the documented (default) approach?

I tested using both approaches and both work in production, once you get past other issues (for e.g. see here and here).

We settled on the simpler second approach since as @ericblade said, the STS approach felt excessive.

The August 2020 version of the 'VendorDevGuide_v1.pdf' documentation only shows the second approach when creating the IAM User with no mention of STS. I think the STS flow was added to the documentation afterwards, and it is in the October 2020 version of 'VendorDevGuide_v1.pdf'.

[ericblade]

hmm. Well, I've got an initial version of my node/javascript library that is working, using the STS method. If both are valid ways of doing this, though, then I might want to support both in my library, as it's intended for other users to be able to use it as well, not just myself.

In either case, it does seem that a major documentation change needs to be made to correctly account for one way, or the other, or both.

Could someone explain how to configure without the STS step, so I can build a test, and see how to architect my lib so it works either way?

[p-prins]

@ramieblatt thank you for your response. Does your solution also work when requesting data from other regions besides the US (i.e. EU / FE)?

[ramieblatt]

@ericblade this is outlined in the second approach outlined by @p-prins (ie you just add your execute API policy directly to the IAM user, which then has both the 'execute-api' policy attached as well as the inline permission to assume-role via STS on the IAM role which also has the 'execute-api' policy attached.

[ramieblatt]

@ramieblatt thank you for your response. Does your solution also work when requesting data from other regions besides the US (i.e. EU / FE)?

Sorry, we only operate in NA (US and Canada).

[ramieblatt]

@ericblade this is outlined in the second approach outlined by @p-prins (ie you just add your execute API policy directly to the IAM user, which then has both the 'execute-api' policy attached as well as the inline permission to assume-role via STS on the IAM role which also has the 'execute-api' policy attached.

BTW, attached here is the August 2020 version of the 'VendorDevGuide_v1.pdf' documentation which only documents the second approach configuration: VendorDevGuide_v1.pdf

[MrYing]

I encountered the same problem, can anyone tell me how to solve it

I have confirmed that my signature is correct, and my access token was just obtained. Programmatic access is displayed on the IAM account, but the returned value is authentication failure. Whose problem is solved, I hope you can give me some guidance.

my request and response context:

`BEGIN REQUEST++++++++++++++++++++++++++++++++++++ Request URL = https://sellingpartnerapi-eu.amazon.com/fba/inbound/v0/shipments/shipmentId1/preorder/confirm?marketplaceid=A1F83G8C2ARO7P&needbydate=2012-10-17

RESPONSE++++++++++++++++++++++++++++++++++++ Response code: 403

{ "errors": [ { "message": "Access to requested resource is denied.", "code": "Unauthorized", "details": "" } ] }`

[ankurmorabia201]

@MrYing I'm facing the same issue. I would like to know how you identified that the signature was correct?

[p-prins]

@ankurmorabia201 and @MrYing this error message is off-topic. Please see other open issues or open a new issue.

[beckyconning]

This is so much, its already extra without the STS stuff.

[Romerolweb]

I encountered the same problem, can anyone tell me how to solve it

I have confirmed that my signature is correct, and my access token was just obtained. Programmatic access is displayed on the IAM account, but the returned value is authentication failure. Whose problem is solved, I hope you can give me some guidance.

my request and response context:

`BEGIN REQUEST++++++++++++++++++++++++++++++++++++ Request URL = https://sellingpartnerapi-eu.amazon.com/fba/inbound/v0/shipments/shipmentId1/preorder/confirm?marketplaceid=A1F83G8C2ARO7P&needbydate=2012-10-17

RESPONSE++++++++++++++++++++++++++++++++++++ Response code: 403

{ "errors": [ { "message": "Access to requested resource is denied.", "code": "Unauthorized", "details": "" } ] }`

Hi, would you mind telling me how to ensure that the signature is well done?, thanks ahead.

[rugved1991]

Hi @ramieblatt @beckyconning @Romerolweb,

If you are still facing an issue, please feel free to comment on the issue. If there is an issue with AWS signature then you would receive "InvalidSignature" error. The unauthorized errors would be related to permissions on the application. Please open a support case if you continue to see this issue to investigate further.

Best, Rugved Solutions Architect, SP API

[github-actions[bot]]

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.

[franclin]

Hi @ramieblatt @beckyconning @Romerolweb,

If you are still facing an issue, please feel free to comment on the issue. If there is an issue with AWS signature then you would receive "InvalidSignature" error. The unauthorized errors would be related to permissions on the application. Please open a support case if you continue to see this issue to investigate further.

Best, Rugved Solutions Architect, SP API

Hi @rugved1991

Would have been nice to answer the initial question as I feel like @p-prins made a valid point:

The second approach has the obvious benefit that it does not require the use of STS.

What are the consequences of using the second approach in production? If there aren't any consequences, why is this not the documented (default) approach?

Thanks

[rugved1991]

Hi @franclin,

It is possible to use IAM User on the app config. But, it is then important to keep the AWS IAM User credentials safe and secure. You should rotate the keys every 90 days. The use of STS tokens helps increase security and reduce the impact of lost keys.

Best, Rugved Solutions Architect, SP API.

[franclin]

Hi @franclin,

It is possible to use IAM User on the app config. But, it is then important to keep the AWS IAM User credentials safe and secure. You should rotate the keys every 90 days. The use of STS tokens helps increase security and reduce the impact of lost keys.

Best, Rugved Solutions Architect, SP API.

Hi @rugved1991

I followed your advice but I am still getting the same error ({ "errors": [ { "message": "Access to requested resource is denied.", "code": "Unauthorized", "details": "" } ]}). I opened a case number (ID: 11263638021) over 2 weeks ago and haven't received any reply from Amazon so far.

Please could you review and advise the way around it?

Thanks in advance.